Mentawai Forum - Mentawai Web Framework

O VOFilter e OVFilter são bacanas, mas eu pensei nisso de uma outra forma.
Vou propor uma outra abordagem para as funcionalidades deles.
Vejam o que acham.

Usando VOFilter e OVFilter:

Aplication Manager:
action.addFilter(new VOFilter(User.class, "user"));

Action:
User user = (User)input.getValue("user");

Resumo:
- 2 linhas de código;
- se houver inner action, todas as inner actions vão ter o "user", mesmo que não for utilizar. Em uma Action de CRUD, só metade das inner actions precisa do "user" (Create e Update).
Se quiser evitar isso, teria que dividir as actions no Application Manager (que são mais linhas de código).

Usando nova abordagem:

Aplication Manager:
- Não precisa escrever nada

Action:
User user = (User)input.copyProperties(User.class);

Resumo:
- 1 linha de código;
- você só usa o recurso quando precisar, ou seja na inner action que precisar;
- eu acho mais intuitivo porque é uma "regra" da Action que está na action, não no Application Manager. Apesar de que a idéia de filters é bem bacana...
- tem como fazer associações mais dinamicas, tipo:
Code:

 	if (input.getStringValue("tipo") != null) {
 		user = (UserLdap)input.copyProperties(UserLdap.class);
 	} else {
 		user = (UserLocal)input.copyProperties((UserLocal.class);
 	}

Alterei os código do Mentawai para suportar isso. Basta ver se é legal ou não.
Obs:
- Tomei a liberdade de criar um AbstractInput, porque tinha muito código repetido entre o InputRequest e o InputMap... Não quis repetir mais um =)

Os códigos estão em anexo são 1300 linhas pq eu mexi em várias classes para organizar o código dos inputs e filter.
Não fiz a parte do output, mas se o pessoal do menta gostar da idéia eu faço, ela é mais tranquila...

To tentando deixar o que já é simples ainda mais simples =)
Só alguns detalhes... kk

bruno, ficou show...mas novamente so vou usar qndo for oficial no menta. Para n acontecer a tal pirataria que vc citou no outro post.
kkkkkk
Tah mandando ver... flw
[]'s

Muito bom, bruno... muito mais intuitivo mesmo... ótima idéia...

Tenho uma duvida, caso eu esteja usando o OVFilter com prefixos ou seja da classe user meus campos vão estar assim: user.name, user.password, etc. O VOFilter vai conseguir pegar corretamente os parametros da input?

Para isso acho que seria necessário mais um atributo no método copyProperties (opcional) dizendo esse prefixo.

Gostei da idéia. Quero pensar nela com mais calma, para ver a viabilidade de fazer desse jeito. Agorra estou meio sem cabeça para pensar nisso, mas pode esperar um feedback mais detalhado em breve, meu e do grupo.

Krycek wrote:

Muito bom, bruno... muito mais intuitivo mesmo... ótima idéia...

Tenho uma duvida, caso eu esteja usando o OVFilter com prefixos ou seja da classe user meus campos vão estar assim: user.name, user.password, etc. O VOFilter vai conseguir pegar corretamente os parametros da input?

Para isso acho que seria necessário mais um atributo no método copyProperties (opcional) dizendo esse prefixo.

hehe, até vi esse prefixo na documentação e no código, mas não considerei isso para o copyProperties()... Se for aprovado eu termino de fazer e coloco o teu prefixo =)

Achei a idéia muito boa! Parabéns Bruno Braga. Seria legal debatermos mais um pouco em torno dela com os membros/desenvolvedores do projeto. Vc receberá os créditos no código do Mentawai pela sua idéia.

O que eu pensei seguindo a sua linha de racioncínio foi:

Novos métodos para a interface Input:

Code:

     public Object getObject(Class klass);
 
     public Object getObject(Class klass, String prefix);
     
     public Object getObject(Class klass, String prefix, boolean tryField, boolean tryToConvert);

Problemas:

- Como usuaríamos o InjectionFilter para injetar um objeto User diretamente na action ????????

- Esse método não possui cache, ou seja, sucessivas chamadas ao método getObject vão fazer todo o trabalho sujo e demorado de injection.

A vantagem do VOFilter é que ele: colocava um objeto no input, fazendo um cache e tb preparando para um eventual InjectionFilter.

Acho que teríamos que fazer assim então:

Code:

     public Object getObject(String name, Class klass);
 
     public Object getObject(String name, Class klass, String prefix);
     
     public Object getObject(String name, Class klass, String prefix, boolean tryField, boolean tryToConvert);

Ou seja, esses métodos vão procurar primeiro por um objeto no input com a chave name. Se encontrarem um objeto, eles checam para saber se o objeto é do tipo klass. Se não for, joga uma exception, se for retorna o objeto. Se não existir objeto nenhum então constrói o objeto e coloca no input com o name passado.

O que vcs acham?

Esse argumento "Name" não poderia ser um qualquer setado por default?

Pergunto isso pq não entendi quando seria necessário utilizar outro "name" na mesma action já que o objetivo é a cache.

O name seria o nome (chave) que vc colocaria ele no input depois de construído !

Mas o getObject não seria um método da interface input? Pq se eu já estou invocando esse método pra que eu preciso saber com que name (chave) foi salvo o objeto?

Sergio, explica melhor a ideia do nome.

saoj wrote:

Ou seja, esses métodos vão procurar primeiro por um objeto no input com a chave name. Se encontrarem um objeto, eles checam para saber se o objeto é do tipo klass. Se não for, joga uma exception, se for retorna o objeto. Se não existir objeto nenhum então constrói o objeto e coloca no input com o name passado.

Bem axo q se o kra não quer usar o filtro e qr usar essa outra forma, ele tem que arcar com o custo da mesma.

Apenas minha opinião.

VELO

Achei a idéia do name um pouco estranha, e não enxerguei bem a sua necessidade.

Para fazer um cache? Não me parece ser comum o cara pegar o mesmo objeto duas vezes no input. E além do mais é bem tranquilo fazer um cachezinho dentro do input, baseado no Class e no prefixo.

A única questão realmente é o InjectionFilter, como você disse.

Bem, na minha opinião deve-se colocar essa funcionalidade proposta pelo Bruno (parabéns!). Aí é mais uma alternativa. Eu mesmo preferiria usar a abordagem do Bruno, para não precisar declaram um filtro... a não ser que eu fosse usar o InjectionFilter.

Opa Sergio, vlw

Eu também acho que não precisa desse name não...
Se é para fazer cache, dá para fazer cache sem ele.
Mas quando você ler o Objeto na action, você vai jogar para uma váriavel como no exemplo, essa váriavel já é o "cache". Não precisa executar o reflection denovo...

Eu tinha chamado o método de copyProperties() porque o Jakarta BeanUtils tem um recurso parecido em esse nome.
Mas getObject() também é legal.

Problemas:

- Como usuaríamos o InjectionFilter para injetar um objeto User diretamente na action ????????

Se eu entendi a pergunta, não precisa de InjectionFilter.
Já fiz o código para ter os objetos na action, veja o meu código.

Ah, dei uma olhada no InjectionFilter do mentawai aqui.
Acho que agora entendi a pergunta.
Você quer injetar o User como atributo da action?

Não vejo solução porque o User não está no input, quem está no input são os dados do User, e depois a pessoa vai decidir o que fazer com eles (qual objeto popular). Ela vai popular e usar na hora.
Meio que eu não vejo solução a principio mas também não vejo necessidade de ser atributo da action.

Mas vou pensar melhor se tem algum jeito de fazer esse Injection.

Na real, se o kra não usar o filtro, não tem injection....

Milagre a gente ainda não faz

kkkkk

Axo q a ideia do Bruno tah show assim mesmo.

Parabens kra.

VELO