Frameworks controladores: webwork?

Dia desses eu li uma análize do Matt Raible sobre os vários frameworks e ele apontou uma coisa interessante do WebWork, os desenvolvedores no projeto não parece estar interessados em fazer com que o framework decole. O WW é só um pouco mais novo do que o Struts e poderia muito bem estar em pé de igualdade com ele ou provavelmente na frente, se tivesse se preocupado em “auto-promoção” como o pessoal do Struts fez, tanto em documentação como em apoio de empresas, também como o pessoal do Spring MVC tá fazendo. Talvez daqui a pouco tempo, o Spring MVC junto com JSF sejam os novos “donos” dos frameworks MVC pra wev. Mas vamos aos pontos:

O livro está pra sair, mas talvez já seja meio que tarde demais, especialmente porque ninguém sabe como é que ele vai tratar a validação. Eu, pessoalmente, gosto primeiro de entender como a coisa funciona pra depois começar a mexer, e os exemplos do WW são exatamente o contrário, eles fazem a mágica e depois você que se lasque pra descobrir quando aparecerem os primeiros bugs.

Eu acho que tanto faz, se der pra testar fora do container, está ótimo, se não der, lascou (mas dá né?).

Era uma coisa que eu tava falando com o Sérgio dia desses, pra mim, “esconder” a API de servlets em um framework MVC é trabalho perdido, o programador deve ser inteligente o suficiente pra não amarrar a sua lógica de negócios a API, mas em muitos casos, a execução da lógica requer o acesso a dados que estão na session, no contexto e aí já viu, tome gambiarra.

Guilherme Silveira:

- necessidade de criar uma classe intermediaria para usar EL, jstl etc, gambiarra numero 1

• forca usar sua propria taglib (ver item anterior)

Eu diria que esses são o pior de todos, ninguém quer aprender mais uma “EL”, quer usar a que é padrão e vai valer em todos os frameworks.

Eu to pulando do Struts e tinha pensado em ir pro WebWork, mas fui atacado pelo Spring e to migrando pra ele, inclusive porque o pessoal se preocupou em montar um conjunto de facilidade pra trabalhar com JSF, que era com o que eu realmente queria trabalhar :mrgreen:

- necessidade de criar uma classe intermediaria para usar EL, jstl etc, gambiarra numero 1

Ah, por isso que dava pau quando eu usava EL no WebWork!

Mauricio, concordo com sua afirmação sobre EL. Agora, por que você está “pulando do Struts” ?

Um abraco

carneiro:

- necessidade de criar uma classe intermediaria para usar EL, jstl etc, gambiarra numero 1

Ah, por isso que dava pau quando eu usava EL no WebWork!

Mauricio, concordo com sua afirmação sobre EL. Agora, por que você está “pulando do Struts” ?

Um abraco

Porque ele tem um suporte muito fraco a transformação de valores, a JSF e é complicado fazer testes unitários nos Actions. Mas ele ainda é referência, especialmente em validação, ninguém bate ele nisso, até a galera do Spring “importou” o Validator :mrgreen:

Eu posso usar o Spring MVC apenas, desacoplado dos outros componentes do Spring?

Pode, só o container IoC é obrigatório.

Mas você tem algum motivo especial pra não usar os outros componentes do Spring?

Bem, o problema é que eu não sei o que é essa tal de Programação Orientada a Aspectos, que pelo visto é a base do Spring, e eu tenho a impressão que o Spring é um pouquinho avancado pra mim…

Talvez seja só impressao, hehe!

carneiro:

Bem, o problema é que eu não sei o que é essa tal de Programação Orientada a Aspectos, que pelo visto é a base do Spring, e eu tenho a impressão que o Spring é um pouquinho avancado pra mim…

Talvez seja só impressao, hehe!

Na maioria das vezes você nem vai ver a AOP funcionando, ela costuma ficar mais por debaixo dos panos. E o Spring é muito besta de aprender, pega um livro bom, como o Pro Spring o o Spring Live e pronto, é só meter a cara.

Papo serio: antes de avaliar qualquer framework Web em Java, passe uma tarde fazendo uma aplicacao com Ruby On Rails. Vao dizer que eu tou fazendo propaganda, sendo extremista, blablabla, mas eh o melhor conselho que eu posso oferecer a quem esta programando pra web: pelo menos teste o Rails.

Humm… nunca fiz, mas olhei aquele artigo que compara j2ee com Rails, e eu vou fazer isso que o CV falou!

E não é por nada naum, pelo que vi, o Rails arregaça a pau mesmo! Mas estive pensando um umas coisas doidas aqui, e acho que em breve poderíamos ter algo muito parecido com o Rails em java, e talvez, nem seja muito complicado!

Em breve quero escrever um artigozinho sobre o assunto! Daí eu vou postar aqui pra galera fazer umas píadas! kiakkk :mrgreen:

Abraços!
Thiago

O objetivo do Mentawai é resolver todos esse problemas do WebWork. Pelo menos é o que estamos tentando fazer. Veja meus comentários abaixo:

Exemplos são fundamentais. O site do Mentawai é todo baseado em exemplos claros.

Não tenho certeza quanto ao WW, mas no Mentawai vc pode tranquilamente implementar Action que tudo vai funcionar. A vantagem de estender BaseAction é que vc não precisa implementar os vários métodos setters da action (setInput, setOuput, setSession, etc) e pode acessar esses caras através de variáveis protected.

Isso é uma coisa básica e se for complicado pelo amor de Deus !!! Não pode de jeito nenhum complicar o básico. No mentawai a session está sempre disponível para a action, podendo ser acessada de forma ridícula.

No XML please !!! (http://www.javaworld.com/javaworld/jw-07-2005/jw-0718-mentawai.html)

Acho que isso é por causa da mágica negra do XML. Vai explicar Interceptor do WW pra alguém! Agora dá uma olhada nos filtros do Mentawai. Até uma criança aprende aquilo. (http://mentawai.lohis.com.br/filters.jsp)

No Mentawai vc pode user JSTL, EL, Velocity. Pode chamar qualquer taglibs de dentro do velocity ou de dentro do JSP. Pode misturar Velocity com JSP (se realmente vc souber o que está fazendo!)

http://mentawai.lohis.com.br/velocity.jsp

Se vc quiser dar uma olhada no Mentawai e ajudar com críticas e sugestões seria ótimo. Tua experiência com VRaptor, WebWork, Struts, etc seria de grande valia na hora de dar suas opiniões.

[color=red]E veja bem. Não estou falando que o Mentawai é melhor que o WebWork. Só estou falando que é 10 vezes mais simples e intuitivo![/color]

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

Quanto a XML de configuração … cara, depois de tudo arrumado bastam 3 linhas para cada action. E ainda tem um exelente plugin pra fazer isso para você. De uma maneira ou de outra você tem que configurar o framework, não importa se é com annotations, com xml, com nomenclatura.

E que classe intermediária??

Sobre ensinar, sério, acho bastante simples. Ação é executada, beans são populador, retorna uma string indicando o resultado e fim!

Pra quê esconder a API de servlets?

LIPE:

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

E quando eu precisar invalidar a sessão ???

Eu posso limpar o conteúdo do componente, mas ainda assim estarei usando a mesma sessão.

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.

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.

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

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

Calma!!! :lol:

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.

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.

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 :mrgreen:

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

LIPE:

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)