JSF 2.0 - Early Draft Review 2

na verdade eu estava falando da especificação WebBeans, que está para sair e vai entrar no Java EE 6:

http://www.seamframework.org/WebBeans

Ainda não é final, mas eu tenho mexido bastante sim! Tem bastante coisa interessante que veio do Guice, Seam, Spring... Vale a pena dar uma olhada para estar preparado.

Debugger Membro desde: 05/06/2006 16:18:04 Mensagens: 55 Offline

marcosalex wrote:Uma desvantagem que eu vejo é o código ficar mais "poluido".
Outra coisa é que se você quiser alterar alguma configuração,vai ter necessariamente de recompilar sua aplicação e dar um deploy novamente, enquanto no xml seria somente editar o arquivo.

O xml não "sobrescreve" as anotações?

mtosatti wrote:

marcosalex wrote:Uma desvantagem que eu vejo é o código ficar mais "poluido".
Outra coisa é que se você quiser alterar alguma configuração,vai ter necessariamente de recompilar sua aplicação e dar um deploy novamente, enquanto no xml seria somente editar o arquivo.

O xml não "sobrescreve" as anotações?

Não em 100% dos casos, mas na maioria sim.

Por exemplo, com EJB3 se você definir um SessionBean para Stateless via anotação, você não pode definir ele como Statefull via XML. Nesse caso o XML não sobrescreve a anotação, porém na grande maioria sobrescreve sim (na verdade, esse é o único caso que eu sei que não sobrescreve).

Jair Rillo Junior wrote:Por exemplo, com EJB3 se você definir um SessionBean para Stateless via anotação, você não pode definir ele como Statefull via XML.

essa é uma situação onde o cara não sabe o que quer, ao configurar desta forma.

faelcavalcanti wrote:

Jair Rillo Junior wrote:Por exemplo, com EJB3 se você definir um SessionBean para Stateless via anotação, você não pode definir ele como Statefull via XML.

essa é uma situação onde o cara não sabe o que quer, ao configurar desta forma.

A questão não é que "a pessoa" não sabe o que quer, pois em teoria, quando se trabalha com EJB3 existem várias roles, assim a role do bean provider (quem fez o componente) pode ser sobrescrita pela role do deployer (quem vai fazer o deploy da aplicação). Mas como eu disse, esse é o unico caso onde o XML não sobrescreve a anotação, pelo contrário, gera problema

Jair Rillo Junior wrote:A questão não é que "a pessoa" não sabe o que quer, pois em teoria, quando se trabalha com EJB3 existem várias roles, assim a role do bean provider (quem fez o componente) pode ser sobrescrita pela role do deployer (quem vai fazer o deploy da aplicação).

isto poderia acontecer entre o Bean Provider e Application Assemlbler e não o Deployer. O Deployer resolve todas as dependências externas configuradas pelos Bean Provider e Application Assemlbler, ele não interfere ou deveria interferir neste aspecto.

mas pode sim acontecer, se a conversa não for bem feita entre ambos.

Jair Rillo Junior wrote:Mas como eu disse, esse é o unico caso onde o XML não sobrescreve a anotação, pelo contrário, gera problema

e como gera!

JavaGuru Membro desde: 26/08/2004 18:45:26 Mensagens: 221 Offline

a uns 3 anos atras o "certo" era xml! dae foi xml para todo lado, tudo(configurações) tinha que esta em xml senão...., agora evoluimos

agora tudo é annotations! tudo tem annotations, o hibernate,spring tem, ejb tem, jpa, guice, struts... agora me diga será que daqui 03 anos não muda novamente ? quem sabe um retorno ao XML ?

ualex wrote:a uns 3 anos atras o "certo" era xml! dae foi xml para todo lado, tudo(configurações) tinha que esta em xml senão...., agora evoluimos agora tudo é annotations! tudo tem annotations, o hibernate,spring tem, ejb tem, jpa, guice, struts... agora me diga será que daqui 03 anos não muda novamente ? quem sabe um retorno ao XML ?

Bem, ainda bem que acordaram e começaram a perceber que XML é uma merda. Um dia quem sabe, quiçá, essa merda será completamente extirpada da face da Terra.

Quanto a annotations, o que poderia vir a substituí-la seria programação tradicional sem XML e nem annotations ou qualquer outra maluquice que inventem no lugar. 100% programático!

Mas, algo que seria legal e infelizmente não tem, seria colocar e retirar annotations de classes, métodos, atributos e parâmetros em tempo de execução, além de annotations mutáveis. Isso daria bastante flexibilidade ao desenvolvedor.

Outra coisa que poderia vir no lugar de annotations seriam closures.

ualex wrote:a uns 3 anos atras o "certo" era xml! dae foi xml para todo lado, tudo(configurações) tinha que esta em xml senão...., agora evoluimos agora tudo é annotations! tudo tem annotations, o hibernate,spring tem, ejb tem, jpa, guice, struts... agora me diga será que daqui 03 anos não muda novamente ? quem sabe um retorno ao XML ?

Dependendo do caso, a Convention over configuration http://en.wikipedia.org/wiki/Convention_over_Configuration pode ser melhor que Annotation (vide o VRaptor ou Rails).

Jair Rillo Junior wrote:Convention over configuration pode ser melhor que Annotation (vide o VRaptor ou Rails).

em que situações, não entendi? exemplifique melhor!

acho que li sobre este padrão no livro de DDD. vou dar uma olhada.

JavaGuru Membro desde: 04/03/2008 07:21:24 Mensagens: 220 Offline

faelcavalcanti wrote:

Jair Rillo Junior wrote:Convention over configuration pode ser melhor que Annotation (vide o VRaptor ou Rails).

em que situações, não entendi? exemplifique melhor!

acho que li sobre este padrão no livro de DDD. vou dar uma olhada.

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é?

Não sabia desse Plugin do Struts 2, vou ver se dou um olhada nele

Jair Rillo Junior wrote: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é?

Na verdade seria ClientesController, e não ClientesAction. O Spring MVC também tem algo parecido:

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)

Jair Rillo Junior wrote: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.