Eu tinha criado um tópico sticky só pra isso... Poucas pessoas responderam... Acho que um forum inteiro pra isso vai ficar sem movimento... :-)  

1) Criar um plugin para trabalhar com JPA.  

2) Dar uma revisada na documentação (pt_br).  

3) A documentação do site(pt_br, eng) deveria ir junto com o framework. Seria um copy and paste mesmo. Pois vejam a seguinte situação na minha empresa eu não consigu acessar nenhum site no horario de trabalho, so no horario do almoço. Chega no horario de almoço eu não tenho acesso ao site do menta pois ele não esta na white list. É uma droga.  

4) Criar um componente de lista paginada. (View).  

5) Integrar o DWR ao framework. Todos não sabemos (pelo menos eu) o quanto este framework e simples e facil de usar. Mas podem falar, o menta ja tem o seu proprio esquema para se trabalhar com ajax (AjaxConsequence). Se o DWR fosse ruim o struts 2 não teria integrado ele. O DWR tem muitas funcionalidades uteis que não precisa ficar reinventando a roda. A util.js e a engine.js são muito utilitarias. Usando o AjaxConsequence voce reinventa a roda escrevendo muitos scripts (js) inuteis. Não estou desmerecendo quem criou. So estou dando uma sugestão. Veja o exemplo no site do menta, (Integração com Ajax). Para trabalhar com ajax voce utiliza muitos scripts com dwr isso ja e implicito. Acho que voces deveriam repensar a forma de se trabalhar com ajax no menta. E nao deixar de lado um framework fantastico que e o DWR. Valeu..  

4) Criar um componente de lista paginada. (View).  

Se vc está falando de uma paginação pura e simples de uma lista, dê uma olhada aqui: Querendpo http://forum.mentaframework.org/posts/list/193.page#3276 Poucos frameworks vão te oferecer isso de maneira simples, eficiente e prática como o mentawai oferece. Se vc estiver falando de uma tag do tipo displayTag, estamos avaliando implementar isso no menta tb, mas a melhor abordagem é usar essa tag junto com o menta. Muitas pessoas já fazem isso. (procure no forum)  

Uma outra sugestão que tenho é de trocar a configuração programática por nenhuma configuração. Eu explico. Ao invés de termos que configrar a action no ApplicationManager poderíamos ter um a chamada diretamenta pela URL. Por exemplo: Cliente.cadastrar.mtw, chamaria o método cadastrar da classe Cliente. Esse método por sua vez retornaria uma consequência ao invés de retornar uma String. O que vocês acham? Essa facilidade pode causar algum problema? 

... 

Cara, se tu registrares no AppManager uma Action e acessar, exemplo: Action.cadastro.mtw, via Reflection o Menta AUTOMATICAMENTE chamará o método cadastro. Entretanto, fazer com que a própria Action retorne uma conseqüência talvez quebre o conceito de "action -> result -> consequence -> view".  

Entretanto, se você realmente desejar usar isso, é possível sim. Basta que seja implementada uma camada secundária que será carregada no carregamento do AppManager e será responsável por, via Reflection, carregar as classes de Action's, adicioná-las ao AppManager. 

... 

thiagoalgo wrote:

... 

Desculpe, eu me expressei mal. A aplicação continuaria tendo a arquitetura correta, o que eu quis dizer é que se a Action retornasse uma Consequence, ela quebraria a arquitetura existente no Menta, Struts e outros que denota que a Action não deve conhecer o destino da requisição. Nesse modelo de request >> action -> view, a Action não deve ser responável por armazenar as informações sobre como o usuário permanecerá na aplicação, logo, ela não deve ""saber" quais são as suas consequências. Fazer com que a Action retornasse uma Consequence iria contra os princípios, creio eu, da lei do menor privilégio (aqui, levemente modificada noutro contexto), o de uma Action deve apenas processar dados e não definir exatamente para onde segue o fluxo. Acho que teria de ser como falei e você concordou: a Action armazenaria num campo suas Consequence`s mas retornaria normalmente um result. Uma camada auxiliar deveria registrar essa Action no AppManager. Ah! Pelo entendi você queria que a Action fosse registrada apenas quando a URL fosse acessada não é? Acho isso completamene fora de cogitação, sei lá, mas acho errado. 

Deixe eu entrar de bicão nessa conversa aqui... Se eu entendi voces estão sugerindo isto? Code:

public Consequence execute(){
   // your code here
   return new Consequence(new Forward("pagina.jsp"));
}

 

Deixe eu entrar de bicão nessa conversa aqui... Se eu entendi voces estão sugerindo isto? Code:

public Consequence execute(){
   // your code here
   return new Consequence(new Forward("pagina.jsp"));
}

Se for mesmo isso é até interessante e uma boa ideia heim... 

package ...
import ...

public class Clients extends BaseAction implements AutoConfigurableAction
  {
   public static Map< String, Consequence > consequences;

   // essas informações não precisam estar em constantes
   private final String RESULT_LIST = "list";
   private final String RESULT_ADD = "add";

   static
     {
      consequences = new HashMap< String, Consequence >();
      consequences.put(RESULT_LIST, new Forward("/view/clients/list.page"));
      consequences.put(RESULT_ADD, new Forward("/view/clients/add.page"));
     }

   public String list()
     { return (RESULT_LIST); }

   public String add()
     { return (RESULT_ADD); }
  }

É isso mesmo. Entretanto, eu estava dissertando com thiagoalgo que eu acho que isso quebraria sim o pattern aplicado pelo Menta, o mesmo que é visto no Struts e noutros frameworks. Eu não sei se tal design pattern tem um nome definido, mas eu me refiro à técnica de fazer com que a Action não seja responsável pelo fluxo que a requisição deve seguir, ou seja, a Action não deve saber para onde exatamente o usuário será redirecionado, sendo assim, a Action não deve retornar uma Consequence.  

Outro fator para o qual apelo em dizer que o método Não deve retornar uma Consequence é que isso exigira mudanças profundas no framework bem como certa modificação massiva no entendimento que temos sobre a configuração de nossas Action's. Não teríamos mais o entendimento que uma Action retorna resultados e cabe ao controller decidir o que fazer, a Action passaria a controlar o que ocorre na requisição. Eu, por isso, acho que seria inviável permitir isso no Menta como feature padrão.  

... 

Da forma como você está implementado a consequência está dentro da classe Action só que com uma complexidade maior. Pelo modelo que voês está propondo a gente não declararia a consequencia no AppMngr, mas sim dentro da action e ainda teria que criar um metodo para isso. Acho que isso quebraria o design pattern (suposto) e ainda aumentaria a complexidade, espalhando configuração dentro das actions.  

thiagoalgo wrote:

... 

Mas você disse que os métodos da Action deveriam retornar uma Consequence, isso necessariamente exigira uma alteração do AppManager, pois ele espera sempre receber uma String e a partir dela procurar por uma Consequence.

thiagoalgo wrote:

Da forma como você está implementado a consequência está dentro da classe Action só que com uma complexidade maior. Pelo modelo que voês está propondo a gente não declararia a consequencia no AppMngr, mas sim dentro da action e ainda teria que criar um metodo para isso. Acho que isso quebraria o design pattern (suposto) e ainda aumentaria a complexidade, espalhando configuração dentro das actions.  

Pois é isto que eu estava tentando explicar, que não cabe a Action saber para onde a requisição deve seguir (ter a conseqüência significa saber o destino da requisição). Se você diz que o método da Action deve retornar uma Consequence, necessariamente a Action terá de saber suas Consequence's. 

robertwgil wrote:

Deixe eu entrar de bicão nessa conversa aqui... Se eu entendi voces estão sugerindo isto? Code:

public Consequence execute(){
   // your code here
   return new Consequence(new Forward("pagina.jsp"));
}

 

Sim Robert, era isso que eu havia sugerido. Eu estava pensando na possibilidade de não necesside registrar as consequências no AppMngr. Tipo... você tem uma classe de ação chamada MinhaAcao com um método execute. Ao invés de você informar isso no AppManager você chamaria a url MinhaAcao.mtw e o método execute retornaria a consequence. Ainda estou meio confuso sobre se isso é certo ou errado, na verdade eu acho que facilitaria muito, apesar de quebrar algum design pattern (não claramente especificado pelo nosso colega YkyMatt). 

Da forma como você está implementado a consequência está dentro da classe Action só que com uma complexidade maior. Pelo modelo que voês está propondo a gente não declararia a consequencia no AppMngr, mas sim dentro da action e ainda teria que criar um metodo para isso. Acho que isso quebraria o design pattern (suposto) e ainda aumentaria a complexidade, espalhando configuração dentro das actions. O que eu estou propondo é basear a configuração em uma convenção. Acho que teu modelo apenas trocou 6 por meia dúzia, ou seja, você ainda precisa configurar.  

??? Se retornar uma Consequence, a configuração fica espalhada. Então como fazer ???  

YkyMatt wrote:

??? Se retornar uma Consequence, a configuração fica espalhada. Então como fazer ???  

Da maneira que estou propondo a configuração também fica espalhada. O que eu quiz dizer é que seu modelo faz exatamente o que eu estou propondo, mas ainda necessita de configuração das actions, que era inicialmente o que eu estava querendo evitar. Assim não necessariamente eu teria uma configuração explícita das minhas actions. Poderia ter essa configuração implícita, baseada em uma conveção.  

O que eu queria era não ter necessariamente uma configuração explícita das minhas actions. Queria poder ter essa configuração implícita, baseada em uma conveção.  

O que eu queria era não ter necessariamente uma configuração explícita das minhas actions.  

O pattern quebrado é o MVC

thiagoalgo wrote:

O que eu queria era não ter necessariamente uma configuração explícita das minhas actions. Queria poder ter essa configuração implícita, baseada em uma conveção.  

http://forum.mentaframework.org/posts/list/765.page voce pode inclusive criar seu proprio CoC facilmente...

thiagoalgo wrote:

O que eu queria era não ter necessariamente uma configuração explícita das minhas actions.  

Agora isso acho impossivel, pois quando eu chamar a action TestAction.mtw , como que o framework vai saber que classe java voce quer chamar? voce pode ter TestAction em varios pacotes etc. Entendeu? 

- Criptografia.  

- CAPTCHA (confirmação por imagem)  

- O mtw:formSkim e mtw:menu são pouco flexíveis a customização de CSS...  

- tá faltando um tag: mtw:else, mtw:elseif ...  

Hoje o mentawai trabalha com <mtw:if test=algo negate=true/false>  

Concordo. O maior problema disso é que o desenvolvimento é todo voltado pra camada de apresentação (HTML, CSS, JS) com as interfaces ricas de hoje em dia acredito que seria melhor focar na integração com flex ou qualquer outra coisa do tipo.