em que situações, não entendi? exemplifique melhor!
acho que li sobre este padrão no livro de DDD. vou dar uma olhada.[/quote]
Por exemplo o vraptor usa isso para o modo como vc tem que acessar suas actions. Não precisa ter um xml ou annotation dizendo que pra vc acessar o método x da classe y precisa chamar pelo nome z. Pelo próprio nome da classe e do método já fica como vai ser a chamada a ela. O Struts 2 tbm possui um plugin para fazer algo bem semelhante.
Como o Renato disse, através da chamada ao método você já informa qual ação e método serão executados.
Faz tempo que não vejo o VRaptor, mas no Rails é assim: Se você chama a seguinte URL: http://suaaplicacao/clientes/cadastro, o Rails irá chamar a Action ClientesAction e o método cadastro, sem XML ou Annotation para mapear essa Action/método. Bem mais simples né? :lol:
Não sabia desse Plugin do Struts 2, vou ver se dou um olhada nele 
Na verdade seria ClientesController, e não ClientesAction. O Spring MVC também tem algo parecido:
@Controller
public class ClientesController {
@RequestMapping
public String cadastro() {
[...]
}
}A URL /clientes/cadastro chama o método cadastro() de ClientesController. Mais informações: http://blog.springsource.com/2007/11/14/annotated-web-mvc-controllers-in-spring-25/
Obrigado pela correção David
Mas então, pelo que eu vi no seu exemplo, você ainda precisa usar duas annotations para isso funcionar, correto? (Não conheço Spring MVC)
É, elas são necessárias. A convenção ai seria usar o nome da classe e do método como padrões para a url, já que é possível fazer coisas como @Controller(“outroNome”) e @RequestMapping(“outroNome”). O Spring utiliza um classpath scanner para buscar beans, e os que possuem a anotação @Controller são expostos via HTTP. O @RequestMapping seria para você poder ter métodos que são expostos e outros que não são. Mas o Spring é bem personalizável (customizável?), de forma que é possível você alterar o comportamento padrão e utilizar esse tipo de convenção sem precisar das anotações.
Espero que melhore a API e sua implementação (Sun RI).
Confesso que já nem tenho tanta vontade de vê-lo, diante de tanta
coisa ruim que já vi nesse framework. Obviamente é fácil atacar pedras,
por isso quero ver com calma.
Quanto ao WebBeans, prefiro nem comentar.
[quote=jonataswingeter]Espero que melhore a API e sua implementação (Sun RI).
Confesso que já nem tenho tanta vontade de vê-lo, diante de tanta
coisa ruim que já vi nesse framework. Obviamente é fácil atacar pedras,
por isso quero ver com calma.
Quanto ao WebBeans, prefiro nem comentar.
[/quote]
Cara, comente com a gente quais esses problemas que voce enfrentou usando a RI e o que voce nem gostaria de comentar sobre o WebBeans. Não to querendo começar aquelas dicussões que não levam a nada, mas seria interessante ver pontos de vista de alguem que passou por problemas.
Eu por exemplo percebi que a qualidade da RI melhorou bastante depois da versão 1.2, tanto que quem usava MyFaces (entre o pessoal que eu conheço) já está voltando pra RI.
Gilliard,
bom dia.
Preciso correr aqui num projeto, mas serei breve.
Não quero malhar livremente o JSF pois sei que vem acalhar em muitos projetos.
Já tive muitos problemas com a parte de browser (comportamentos) devido
a má codificação de scripting, falta de testes neste sentido.
Utilização de Ajax. Muitas requisições são feitas no ciclo do JSF quando se usa,
por exemplo, um A4J. Tem muita abstração na API que a torna a implementação
(qualquer uma) verbosa. A concepção do ciclo de vida é muito extensa (6 fases)
e quando se utiliza ajax nisso aí, exige-se muito cuidado. Aí é melhor você partir
para um DWR, que em contrapartida, exige maior codificação, com um pouco mais
de controle. (Nem pense usar um IceFaces ou RichFaces…aí mesmo vira uma bomba…
péssima qualidade na concepção destes frameworks de componentes).
Converters básicos que deveriam ser inerentes (converter de objeto para SelectItem, ex).
Aí fizeram a implementação no Seam pra resolver as coisas “básicas” que deveriam
ter no JSF, como escopo de conversação.
Outra coisa, JSF não aguenta alta demanda. Com o Seam junto talvez ajude no quesito memória.
Já vi tanta aplicação feita em JSF que em pouco tempo já levantava um “PermGen error” ou
"OutOfMemory Error". Claro que aí caímos na qualidade da aplicação, porém, o framework
em si já deveria prover recursos que ajudassem o desenvolvedor a tomar o caminho correto
(como no Seam).
Eu nem falei dos bugs…pois isso existe em todo framework, mas no JSF RI da Sun tem bastante.
No MyFaces nem se fala…Já ajudei o time da apache com bug tracking.
Seam tem lá suas qualidades…mas é somente um precursor do WebBeans.
Porque não gosto do WebBeans? Porque é uma mescla de JSF + EJB + JPA.
Um projeto pode não precisar de tais tecnologias, e aí você vai ver muito
projeto utilizando essas coisas aí que não precisariam (já existem muitos).
Na década de 90 tinhamos os problemas de Client-Server. Fomos para web, e surgiu
os problemas dos browsers, separação de camadas, etc.
Veio o AJAX, trazendo conceitos inovadores, porém, trouxe outros problemas.
Em meados de 2009, estamos voltando ao conceitos de mais de 10-15 anos atrás.
Tá tudo complicado demais. Precisamos de simplificações (a arquitetura
AMIDAS era bem melhor que muita coisa por aí).
E pra finalizar: Menos significa mais.
Valeu,
Realmente posso te dizer que já passei por quase todos esses problemas que voce mencionou, mas isso há 1 ou 2 anos atras. Realmente o ajax na unha com jsf é bem complicado, mas com Ajax4Jsf não tive problemas não. Porém só comecei a usar depois que liberaram o RichFaces, então se era mais problemático antes disso eu não peguei essa época. Sobre o que voce falou sobre menos ser mais é totalmente válido, pois um ponto negativo é que hoje temos que usar várias coisas juntas para ficar bom: JSF + Coleção de componentes (uso o RichFaces) + algo para ajax (o RichFaces já tem pois inclui o ajax4jsf) + alguém com controle de contexto mais inteligentes (uso o Seam). JSF sozinho realmente deixa a desejar em detalhes como a falta de um entityConverter e um selectItems mais esperto, mas Hoje em dia não da mais pra usar JSF sozinho, tem que ter um Facelets (no 2.0 já vai estar integrado) e um Seam pra ficar bom.
Esses problemas que voce comentou que teve com o IceFaces e RichFaces eu tive com os componente Tomahawk, mas isso também quando eu usava há 1 ou 2 anos… de lá pra cá tenho usado o RichFaces sem maiores problemas, pois sempre tem versão e os bugs são corrigidos rapidamente.
Além disso com o ajax4jsf até agora não tive problema com excesso de requisições ou de dados enviados/recebidos pois dá pra especificar certinho o que vai e volta.
Um problema que eu vejo que aconte atualmente é a incompatibilidade de bibliotecas de compontenes, mas com a padronização de js que virá no JSF 2.0 isso também tende a diminuir. E sobre problema de memória, eu já vi isso acontecer em aplicações onde não tem alguém gerenciando o contexto, como o Seam por exemplo, e o desenvolvedor fica toda hora jogando e pegando dados da sessão (e acaba esquecendo coisa lá algumas vezes). Mas isso faz aplicação sentar em qualquer tecnologia. Agora pelo fato do JSF manter o estado da árvore de componentes, com certeza usa mais memória, mas nunca vi isso chegar a fazer uma aplicação sentar sem estar associado com os erros que comentei.
Mas apesar de hoje em dia eu não sofrer desses problemas que voce comentou (no passado já), é sempre bom ter críticas de quem não critica sem nunca ter visto.
Essa parte não entendi. Em que sentido ele é uma mescla dessas três coisas que fazem coisas totalmente diferentes?
Se você dissesse que é uma mescla de guice, spring ioc e picocontainer eu até entenderia (e concordaria)
Por sorte eu começei com o hibernate direto nos annotations e achei tudo fáçil, quando começei a usar o xml pra jsf achei mais difiçil.
E a classe não fica tão poluida assim, já que a maioria das anotações vão ficar na declaração da classe e dos atributos, não são todos os métodos que precisam delas também, e na minha opnião, tornando o código mais limpo.
"
[quote=jonataswingeter]"(Nem pense usar um IceFaces ou RichFaces…aí mesmo vira uma bomba…
péssima qualidade na concepção destes frameworks de componentes). "[/quote]
Discordo totalmente. O Richfaces/A4J é uma excelente suíte com uma excelente qualidade (aliás, o uso muito). Conversando com o Ed Burns depois do TDC deste ano, perguntei se ele gostava do IceFaces (já que eu, o Vinicius Sengers e outros estavamos batendo uma papo sobre esta suite e suas incompatibilidades, entre outras coisas). O Ed foi enfático em afirmar que gosta do Icefaces e acha uma ótima suíte… suas imcompatibilidades com outros componentes (como com o a4j, por exemplo), é decorrentes da não especificada implementação AJAX para componentes JSF (situação corrigida para a versão 2.0) e de nada tem haver com qualidade do framework.
A Stack Solution oferecida pelo Seam “contém” os elementos que estão na JSR do WebBeans, mas ele incorpora muuuuuitas outras features. Desde sua Api “Persistence” Framework, passando por BPM, segurança e pageflows, isso de nada tem haver com webbeans.
[quote=jonataswingeter]Porque não gosto do WebBeans? Porque é uma mescla de JSF + EJB + JPA. Um projeto pode não precisar de tais tecnologias, e aí você vai ver muito
projeto utilizando essas coisas aí que não precisariam (já existem muitos). [/quote]
Hã? E pq não você não teria com o Seam: GWT + POJO + Hibernate ? Ou Flex + Spring + JPA ? O Seam não manda em como você vai montar sua arquitetura…
Essa parte não entendi. Em que sentido ele é uma mescla dessas três coisas que fazem coisas totalmente diferentes?
Se você dissesse que é uma mescla de guice, spring ioc e picocontainer eu até entenderia (e concordaria)[/quote]
Fábio, bom dia.
Desculpe ser minimalista em minhas colocações, é devido ao tempo mesmo.
Eu acompanho a JSR-299 a um tempo…minha colocação foi em relação ao resumo dessa frase:
The purpose of this specification is to unify the JSF managed bean component model with the EJB component model, resulting in a significantly simplified programming model for web-based applications.
Abraço,
Olá Alessandro, bom dia.
Vou te responder:
[quote=Alessandro Lazarotti][quote=jonataswingeter]"(Nem pense usar um IceFaces ou RichFaces…aí mesmo vira uma bomba…
péssima qualidade na concepção destes frameworks de componentes). "[/quote]
Discordo totalmente. O Richfaces/A4J é uma excelente suíte com uma excelente qualidade (aliás, o uso muito). Conversando com o Ed Burns depois do TDC deste ano, perguntei se ele gostava do IceFaces (já que eu, o Vinicius Sengers e outros estavamos batendo uma papo sobre esta suite e suas incompatibilidades, entre outras coisas). O Ed foi enfático em afirmar que gosta do Icefaces e acha uma ótima suíte… suas imcompatibilidades com outros componentes (como com o a4j, por exemplo), é decorrentes da não especificada implementação AJAX para componentes JSF (situação corrigida para a versão 2.0) e de nada tem haver com qualidade do framework.[/quote]
Já usei bastante o RichFaces e A4J. Obviamente ele tem sua qualidades. Minha intensão não é “sentar a lenha” ou criar flame, fique tranquilo. Eu digo que o que ele se propõe em fazer, deixa muito a desejar ainda.
Por exemplo, o nível de tráfego de dados das árvores dos componentes (isso é mais culpa do JSF) e o browser; A qualidade da programação JavaScript (verbosa e muitos bugs)…aquela DataTableScroller é um exemplo; Integração com o Facelets funciona bem para telas simples. Basta aumentar a complexidade que começa a surgir os problemas. Aliás, não gosto do Facelets também. Faz uma grande gambiarra no response (usando NekkoFilter e outros) para converter ao XML e ser lido pelo Browser…Javascript e XHTML não se dão muito bem, que diga o Firefox.
A Stack Solution oferecida pelo Seam “contém” os elementos que estão na JSR do WebBeans, mas ele incorpora muuuuuitas outras features. Desde sua Api “Persistence” Framework, passando por BPM, segurança e pageflows, isso de nada tem haver com webbeans.[/quote]
Sim, o Seam tem suas qualidades. Eu acompanho o Seam e ele surgiu como um teste para a concepção do WebBeans e para corrigir as burradas do JSF, é claro.
[quote=Alessandro Lazarotti][quote=jonataswingeter]Porque não gosto do WebBeans? Porque é uma mescla de JSF + EJB + JPA. Um projeto pode não precisar de tais tecnologias, e aí você vai ver muito
projeto utilizando essas coisas aí que não precisariam (já existem muitos). [/quote]
Hã? E pq não você não teria com o Seam: GWT + POJO + Hibernate ? Ou Flex + Spring + JPA ? O Seam não manda em como você vai montar sua arquitetura…[/quote]
Se eu uso GWT, posso fazer modelar sem precisar do Hibernate…não vem tecnologias on-demand.
Flex? Flex é tecnologia de visualização. Nada tem haver com Spring + JPA.
Seam realmente não manda como você vai usar sua arquitetura, desde que você use JSF, EJB… E realmente espero que o Seam continue assim…porque se a idéia de transformar em um framework agnóstico de tecnologia de visualização vingar, aí será o fim (JIRA com 3000 tickets por dia).
A idéia é quanto menos você tiver, mais você ganha.
Abraço,
Já está disponível (desde ontem) a implementação da EDR2 para download aqui. Agora não precisa mais usar a nightly build pra testar as novas funcionalidades. Boa diversão 
não sabia que o codname do projeto é Mojarra, interessante. 
é interessante poder conferir estas novas features do novo JSF 2.0 e saber valer a pena para nossos próximos projetos.
achei legal a apresentação de Ed Burns no Java One 2008. bastante objetiva e didática!
http://developers.sun.com/learning/javaoneonline/2008/pdf/TS-5979.pdf
Very guda!
"