[Logo] Mentawai Forum - Mentawai Web Framework
  [Search] Search   [Recent Topics] Recent Topics   [Members]  Member Listing   [Groups] Back to home page 
[Register] Register / 
[Login] Login 
Messages posted by: bruno.braga  XML
Profile for bruno.braga -> Messages posted by bruno.braga [226] Go to Page: Previous  1, 2, 3 ... 13 , 14, 15, 16 Next 
Author Message
=)
É, o prefix já é mais útil =)
Tipo, só pensando também:

Precisa desses 2 campos? tryField, tryToConvert
Não pode ser sempre true, true?

Fala um exemplo de que true, true seja ruim...

O cara quer setar o objeto, não importa se vai ser por set ou forçando o private, importa?

O cara quer setar o objeto, então se não converter os tipos não da para setar, pq o sujeito ia colocar false nisso?

Só pensando...
nossa...

Bom, aqueles métodos getDoubleValue, getBooleanValue eu acho que vão ser muito menos usados heheh...
Pelo menos eu não acho legal ficar pegando atributo por atributo do input usando esses métodos... Eles são só para algum caso que não exista bean ou é necessário pegar um ou outro campo manualmente, então não vão ser muito usados. Mas estão lá para quem precisar porque pode ser útil.

Quanto ao getObject(), nem todo mundo vai usar o ModelDriven, então acho que é bem útil, intuitivo e fácil. As pessoas vão preferir usar o getObject() do que o VOFilter()... Tem todas aquelas vantagens que a gente já falou.



Tem que fazer o contrário também...
O output.setObject() para fazer o mesmo que o OVFilter...

Eu só codifiquei o input porque tinha que ver se funcionava e se iam achar legal...

Quer que eu faça algo?

Acho que o name seria bobeira então. Eu estava pensando na possibilidade do cara querer popular dois objetos a partir da mesma classe, mas aí ou os objetos seriam totalmente iguais, ou ele teria que usar prefixo para separá-los.
 

Mas o cara pode popular quantos objetos quiser:
Code:
 User user1 = (User)input.getObject(User.class);
 User user2 = (User)input.getObject(User.class);
 UserPro userPro = (UserPro)input.getObject(UserPro.class); 
 

Por isso eu não entendi esse esquema de manter no input e de ter name... Nesse exemplo ai dá para colocar os prefixos para separar os dados ainda...

Mas blz é polemico, não vou tentar entender hehehe... =)

-------------------------------------------------

É eu acho que Injection tem que ser pelo VOFilter...

Velo, o que eu tinha falado (sugerido como opção) é isso:
Code:
 
 public class HelloWorldValidator implements InputInjection {
    private Usuario usuario;
    private Empresa empresa;
    private UsuarioDetalhes usuarioDetalhes;
 
 
    public Object[] initInputInjection() {
        Object[] objetos = {usuario, empresa};
        return objetos;
    }
 }
 
 

Esses 2 objetos usuario e empresa que estão no initInputInjection() seriam inicializados pelo InjectionFilter com dados do input.
A parte do name eu ainda não entendi ou vi necessidade =)
Não sei porque precisa ter os objetos no input... !?
E isso nem ajudaria o InjectionFilter porque o Injection acontece antes... e o getObject depois...

Uma outra opção para o InjectionFilter funcionar seria criar uma outra Interface para o Action. Como tem para validação...
Ela melhoraria o controle daquela possibilidade milagrosa que eu tinha falado hehe...

A interface teria um initInputInjection() que retorna um Object[], esses Objects seriam os atributos que devem sofrer injeção automática dos dados do input...
Só que ficaria sem prefixo...
É o que eu falei, ele é intrometido...
Mas você pediu algo milagroso kkkk =)

Podia ter um atributo true ou false para habilitar isso, mas ainda sim seria para a aplicação toda vista que o InjectionFilter é global... Então é uma questão difícil mesmo.

Também a gente tem que bater num cara que quer deixar um atributo null na action né? Fala sério...
Mas por falar em milagroso, jeito meio milagroso até tem... (apesar de intrometido)

Se o cara colocar InjectionFilter, e no input não tiver o objeto para ser injetado, o InjectionFilter pode tentar popular os atributos do atributo da Action com os dados do input =)

Tipo:
Code:
 Action:
 private User user;
 
 Application Manager:
 InjectionFilter ativado sem VOFilter
 

Resultado:
O InjectionFilter não vai conseguir popular o user, porque não tem referencia para ele no input.
Então ele pode tentar entrar no User e popular todos os seus atributos com os dados do input.

Esse é o único jeito que eu imagino...

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.
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.

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 =)
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
??

Mas o botão precisa dar submit ou só acionar a action?

Se for dando Submit dá para fazer mais ou menos com o código que você postou. Tente assim:

Code:
 <input type=button value="aqui" onClick="document.nomeformulario.action.value = 'novaaction.mtw'; document.nomeformulario.submit();">
 


Substitua o nomeformulario pelo nome do seu form.

Agora se não precisar de submit, assim é uma opção:

Code:
 <input type=button value="aqui" onClick="document.location.href = 'novaaction.mtw';">
 

g4j wrote:

RubemAzenha wrote:
...
Uma das vantagens da i18n do Mentawai em relação ao Struts\JSTL, por exemplo, é que você não precisa restartar sua aplicação quando altera uma mensagem internacionalizada.

 


Hmm, como funciona isso? Sempre é feito I/O para o arquivo de mensagens???? Como fica a questao da performance? 


O pessoal do Menta pode responder melhor... Mas vi que tem um cache do arquivo...
O arquivo é carregado 1 vez, e tanto o objeto File (do Java) quanto o conteúdo do arquivo ficam na memória (em cache).
Toda vez que precisa de pegar alguma key do arquivo, é utilizado o cache. Então não tem I/O toda hora.

Para atualização do cache, como é armazenado o objeto File (que como sabemos não tem o conteúdo do arquivo, mas é uma "referencia" ele), da para acessar o metodo lastModified() e saber quando o arquivo teve alteração.
Então, quando a data do arquivo é modificada, a atualização do sistema de cache (para esse arquivo) é disparada.

Para não ficar verificando a data do arquivo toda hora existe um intervalo de 30 em 30 segundos para garantir performance e evitar acessos desnecessários ao objeto File. Então na pior das hipoteses a internacionalização vai ser atualizada em 30 segundos, mas pode ser em menos claro...

É algo mais ou menos assim... =)
 
Profile for bruno.braga -> Messages posted by bruno.braga [226] Go to Page: Previous  1, 2, 3 ... 13 , 14, 15, 16 Next 
Go to:   
Powered by JForum 2.1.6 © JForum Team