Frameworks controladores: webwork?

louds wrote:

Maurício Linhares wrote:

LIPE wrote:Não acesse a Session oras. Declare um componente com o lifecycle "bounded" à sessão e injete-o em suas ações. Pronto!

Pra quê esconder a API de servlets?

Jamais faça um mock de uma classe que você não controla. Nos teus sistemas web você que implementa HttpSession? Não ter que lidar com API de plumbing é uma mão na roda para testar o código.

Mas se eu to testando exatamente isso, a interação do meu action com uma session (porque só quem tem que ver a API é o Action), eu vou ter que fazer gambiarra sempre que tiver que testar ela?

Eu acho que HttpSession, HttpSevletRequest e HttpServletResponse tem interfaces bem definidas o suficiente pra saber o que elas fazem ou não. Fazer um mock delas não vai mudar muita coisa do meu teste não, já ter que ficar usando indireção (chamando método aqui e método ali) pra fazer o mesmo vai me dar muito mais trabalho.

louds wrote: Nos teus sistemas web você que implementa HttpSession?

E quem é que implementa o objeto que o framework vai usar pra empacotar a api de servlets?

Maurício Linhares wrote:

louds wrote: Nos teus sistemas web você que implementa HttpSession?

E quem é que implementa o objeto que o framework vai usar pra empacotar a api de servlets?

Calma!!!

O Framework que faz isso, não vc. Essas classes (Ex: InputMap, OutputMap, SessionMap, etc.) já vem com o framework e não são mocks e sim classes concretas que podem ser utilizadas diretamente, sem a API de servlets por trás. Isso é bom para testes.

Se vc não gosta nem disso, pode injetar seus atributos diretamente na action e ignorar totalmente essas classes, em produção e tb nos testes.

Não vamos fugir do tópico em questão. Vc se sente bem usando HttpServletRequest, HttpServletResponse, HttpSession e suas milhares de funções http related. Na minha humilde opinião, eu acho melhor abstrair essa zona em classes ridículas (Input, Output e Context) que facilitam o MVC. Vc não quer dar a brecha do cara facilmente chamar um response.sendRedirect de dentro da sua action. Se o cara se sente tão a vontade com a API de servlets, então ele não precisa de framework nenhum e poderia continuar vivendo com Servlet/JSP puro.

saoj wrote:Se o cara se sente tão a vontade com a API de servlets, então ele não precisa de framework nenhum e poderia continuar vivendo com Servlet/JSP puro.

Precisa, quem é que vai fazer transformação de dados? Validação? Controle de fluxo? Fazer isso na mão dá trabalho.

Estar a vontade com a API de servlets é uma necessidade, porque muitas vezes em uma aplicação web você precisa acessar ela pra fazer as coisas. Esse é um dos maiores vacilos do WebWork, querer dar conta do que a API padrão já resolveu com EL e JSTL.

saoj wrote: Se vc não gosta nem disso, pode injetar seus atributos diretamente na action e ignorar totalmente essas classes, em produção e tb nos testes.

Isso é ótimo, mas como eu já disse, sempre existem necessidades de usar a API de servlets e elas são muito mais comuns do que se imagina.

E voltando ao tópico, use Spring e JSF, problema resolvido

GUJ Expert Membro desde: 12/03/2003 11:25:57 Mensagens: 4680 Offline

Sérgio, se você *precisa* acessar a sessão para invalidá-la (bem lembrado), basta fazer:

Não, não é bonito, mas não consigo imaginar nenhuma outra situação para acessá-la hehe

This message was edited 1 time. Last update was at 21/07/2005 12:01:38

LIPE wrote:Sérgio, se você *precisa* acessar a sessão para invalidá-la (bem lembrado), basta fazer:
ServletActionContext.getRequest().getSession();
Não, não é bonito, mas não consigo imaginar nenhuma outra situação para acessá-la hehe

Na hora de testar isso ferrou !!! Vai ter que usar um mock para request e um para session.

Eu abstraí a session num interface ridícula chamada Context. Além de setAttribute, getAttribute, hasAttribute, removeAttribute, Context tem uma função útil chamada reset().

Quando vc chama essa função no SessionContext ele invalida o HttpSession que está por trás, chama req.getSession(true) e coloca uma session novinha lá no lugar.

Se vc chama reset num ApplicationContext recebe um OperationNotSupportedException.

No ContextMap que implementa Context mas não tem nada haver com a HttpSession, o reset apenas limpa o map. Esse cara é o que vc pode utilizar para testes!

E todos foram felizes e não foi preciso usar as APIs de servlet !!!

Oi Lipe,

Acho que voce foi o que chegou mais perto das respostas que eu queria.

Criar um objeto que eh injetado que controla a sessao foi a minha solucao (alias, nele tem um metodo invalidate que delega pra sessao, resolvendo o problema do sergio).

O meu problema eh que como voce mesmo disse, depois de bem configurado fica dois palitos o uso do webwork. O problema eh configurar bem esse brinquedo. Para quem tem mais experiencia com outros frameworks e mvc eh dois palitos.

Agora o que voce acha mais simples, ter que criar a classe que controla sessao e injeta-la ou ja existir a classe que controla sessao de alguma outra maneira e nao me preocupar em delegar isso?

Sei que sao pontos de vista diferentes. Como eu disse, pra ensinar pessoas que estao vendo o seu primeiro ou segundo framework baseado em mvc fica mais dificil.

(ps: depois eh 3 linhas mesmo)

Alias, aproveitando, lipe, como voce faz quando vc tem o seguinte fluxo de logica: (duvidas)

loadLista1() -> loadLista2() -> formulariocomselect.jsp

1. eu fiz tres acoes diferentes que estao encadeadas por result type=chain, correto?

2. (mas e ai preciso que meu interceptador que me fornece o dao se preocupe com o caso da chain e fica um codigo bem feio para esse interceptador)

3. mas ai supoe que agora tenho outra acao que tambem deve seguir aqueles tres caras la de cima mas mostrar um jsp diferente... como fazer isso sem criar novamente aquelas duas actions? eh possivel?

ps: ensinar o basico que voce falou eh simples, o problema eh quando cai no ioc usando o ww, o pessoal sofre (experiencia pratica com alunos)

Notícias, artigos e o maior fórum brasileiro sobre Java