Frameworks controladores: webwork?

Muito tempo atras na hora de fazer o guj2 pensamos em usar o webwork2 ainda em beta... alem da falta de documentacao e quantidade de bugs na epoca (ainda em beta) o webwork nao garantia certa produtividade que eu precisava.

Hoje em dia, mais de um ano e meio depois me deparo com a seguinte situacao no webwork2:
- ainda falta documentacao clara, sem ser baseada em exemplos. cade o guia de referencia?
- obrigar extender uma classe
- sistema estranhissimo de acessar a sessao programaticamente
- xmls e mais xmls (pelo menos melhores que no struts), desde o xwork ate o components
- dificuldade no ensino. para dar aula o struts ja eh dificil, o webwork nao facilita muito, mas ja quebra algum galho
- necessidade de criar uma classe intermediaria para usar EL, jstl etc, gambiarra numero 1
- forca usar sua propria taglib (ver item anterior)

Queria marcar minha tristeza aqui e perguntar quem sugere o que. Claro que essa eh a minha experiencia, as vezes algo que eu falei aqui voces tem variacoes melhores..... por favor, novidades?

Att

Guilherme

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:

Guilherme Silveira wrote: - ainda falta documentacao clara, sem ser baseada em exemplos. cade o guia de referencia?

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.

Guilherme Silveira wrote: - obrigar extender uma classe

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

Guilherme Silveira wrote: - sistema estranhissimo de acessar a sessao programaticamente

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

JavaEvangelist Membro desde: 07/04/2005 11:37:42 Mensagens: 328 Offline

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

JavaEvangelist Membro desde: 07/04/2005 11:37:42 Mensagens: 328 Offline

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

carneiro wrote: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?

JavaEvangelist Membro desde: 07/04/2005 11:37:42 Mensagens: 328 Offline

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

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

cv wrote: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

Abraços!
Thiago

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

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

Guilherme Silveira wrote:
- ainda falta documentacao clara, sem ser baseada em exemplos. cade o guia de referencia?

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

Guilherme wrote:
- obrigar extender uma classe

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.

Guilherme wrote:
- sistema estranhissimo de acessar a sessao programaticamente

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.

Guilherme wrote:
- xmls e mais xmls (pelo menos melhores que no struts), desde o xwork ate o components

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

Guilherme wrote:
- dificuldade no ensino. para dar aula o struts ja eh dificil, o webwork nao facilita muito, mas ja quebra algum galho

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)

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

- forca usar sua propria taglib (ver item anterior)

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

Guilherme wrote:
Queria marcar minha tristeza aqui e perguntar quem sugere o que. Claro que essa eh a minha experiencia, as vezes algo que eu falei aqui voces tem variacoes melhores..... por favor, novidades?

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.

E veja bem. Não estou falando que o Mentawai é melhor que o WebWork. Só estou falando que é 10 vezes mais simples e intuitivo!

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

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!

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?

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!

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.

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.

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