JSF 2.0 - Early Draft Review 2

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.

A do fonte poluído eu até concordo, mas o deploy não...quem vai alterar alguma XML com a aplicação em produção? Na prática tudo mundo deburra -> atualiza -> levanta.

faelcavalcanti wrote:vamos lá, quais são as desvantagens que vocês encontraram ?

A única desvantagem que eu vejo é que as configurações ficam espalhadas. Mas nada que uma boa organização de pacotes não resolva. Prefiro assim do que editar XMLs

This message was edited 1 time. Last update was at 25/09/2008 16:07:35

Olha, essas coisas são bem opiniões pessoais mesmo, mas vamos la.

Uma desvantagem que eu vejo é a dependencia entre as classes, mas isso não chega a ser problema pq dificilmente se voce começou um sistema com JSF + JPA vai do nada jogar tudo fora e mudar. E se for fazer isso, remover as anotações será o menor dos problemas.

Outra coisa que eu acho chato com anotações é que eu não consigo estender uma anotação. Deixa eu exemplificar:
Imagine que eu tenho uma classe anotada com @Entity, mas aí eu também quero anotar ela com @Bla, que é uma anotação minha, que eu fiz no meu sistema. Mas vamos supor que eu sei que vou usar essa anotação nos mesmos casos que a @Entity, mas eu não consigo subistituir a mesma pra quando o Hibernate perguntar pra minha classe se ela é um Entity o @Bla responder que sim. Como seria com um instanceof da vida dando um extends em uma interface.
Então as vezes a gente acaba tendo exemplos com um monte de anotações uma em cima da outra... porque uma define o nome do componente, outra define o escopo, e outra define como vai integrar com sei-lá o que.

Mas as vantagens no meu ponto de vista compensam. Como o marcelomartins falou, fica tudo num lugar só (classe e sua respectiva configuração), fácil de encontrar. Sem contar que além de estar no mesmo lugar aquilo é compilado e tem autocomplete. Porque se fosse ver só por estar no mesmo lugar, com XDoclet a gente já conseguia bastante coisa, mas sem dúvida (minha opinião) com anotações fica mais fácil.

Agora sobre o deploy, eu acho que a grande maioria dos frameworks que suportam anotação, continua suportando xml, e com uma precedencia maior justamente pra esses casos. Então se voce precisa mudar algo que com um xml resolve, põe lá que ele vai sobrescrever as anotações. Aí quando voce realmente precisar mudar algo, vc já atualiza as anotações se for possível.

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.

Esse lance de ter que recompilar e refazer o deploy é a grande desvantagem de Annotation em relação ao XML.
Em ambientes de grandes empresa, solicitar um redeploy em uma aplicação é o equivalente a três partos normais ao mesmo tempo, de três mulheres histéricas juntas, em uma sala de três metros quadrados.

Abraços a todos.

marcosalex wrote:Uma desvantagem que eu vejo é o código ficar mais "poluido".

acho bastante válido. as pessoas ainda estão se acostumando, assim como o faziam com o uso de generics.

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

acho que aí cabe o bom censo do uso. levando em consideração que o xml sobrepõe qualquer anotação, então as configurações genericas e mais abrangentes podem ficar no xemelê, não necessitando em alguns pontos o uso de anotações.

alguma desvantagem mais?

marcelomartins wrote:A única desvantagem que eu vejo é que as configurações ficam espalhadas. Mas nada que uma boa organização de pacotes não resolva. Prefiro assim do que editar XMLs

uma outra desvantagem que vejo é nos merges no uso de controle de versão, em XML é um zaralho. o uso de anotações diminui este problema porque você está atualizando o artefato que você desenvolveu ou atualizou e fica mais próximo de saber o que será integrado em uma baseline, por exemplo.

lgi2020 wrote:Esse lance de ter que recompilar e refazer o deploy é a grande desvantagem de Annotation em relação ao XML.
Em ambientes de grandes empresa, solicitar um redeploy em uma aplicação é o equivalente a três partos normais ao mesmo tempo, de três mulheres histéricas juntas, em uma sala de três metros quadrados.

eu até concordo que é um complicador, mas num ambiente que tenha controle de versão e com uma IDE, e alguns target's via ANT ou MAVEN você consegue fazer isto rapidinho.

é só baixar do seu controle de versão efetuar a mudança ou configurar para que seu script faça-o para você.

lembrem-se que só o fato de ser XML não elimina a necessidade do restart/redeploy. O framework (ou a aplicação) precisa explicitamente recarregar as configurações no arquivo quando detectar que ele mudou (ou então reparseá-lo sempre que for usar algo).

Quase ninguém faz isso. Então de qualquer forma precisa reiniciar sim o contexto, mesmo a configuração estando em XMLs.

faelcavalcanti wrote:

lgi2020 wrote:Esse lance de ter que recompilar e refazer o deploy é a grande desvantagem de Annotation em relação ao XML.
Em ambientes de grandes empresa, solicitar um redeploy em uma aplicação é o equivalente a três partos normais ao mesmo tempo, de três mulheres histéricas juntas, em uma sala de três metros quadrados.

eu até concordo que é um complicador, mas num ambiente que tenha controle de versão e com uma IDE, e alguns target's via ANT ou MAVEN você consegue fazer isto rapidinho.

é só baixar do seu controle de versão efetuar a mudança ou configurar para que seu script faça-o para você.

O problema é que muitas empresas de grande porte não permitem que empresas de desenvolvimento terceirizado tenham acesso direto ao servidor de aplicações.
Um exemplo que acontece em minha empresa:
Prestamos serviço para uma grande empresa brasileira.
Para alterarmos uma aplicação em um Wesbsphere 8.1, temos que enviar o pacote para o cliente que solicita à equipe de infra da empresa que inspecione o pacote e realize o deploy da aplicação. Sempre assim. E o deploy tem hora certa para poder ser feito.
Se houver a necessidade apenas de alterar um arquivo .properties ou um .xml, podemos solicitar a alteração por e-mail e as coisas andam mais rápido, já que, uma vez que a própria equipe de infra do cliente efetuará a alteração e não haverá inspeção de pacote.

Por isso, eu, que também não sou muito fã de ficar escrevendo xmls, em alguns casos, defendo sua utilização.
Acho que poder escolher entre usar os xmls ou não é a chave do sucesso.
Num caso como esse que citei, xml é a saída.
Mas em uma outra aplicação, em outro cliente, usaria annotations com todo o prazer.

Abraços.

This message was edited 1 time. Last update was at 26/09/2008 23:46:50

Fabio Kung wrote:Quase ninguém faz isso. Então de qualquer forma precisa reiniciar sim o contexto, mesmo a configuração estando em XMLs.

apesar de quase ninguém o fazer, porém deve-se estar preparado em um pior caso por exemplo, e neste caso você poderá adicionar algumas configurações adicionais via xml sobrepondo qualquer configuração anotada, já que virou bytecode compilado a partir do código java.

editado: adicionando citação abaixo.

lgi2020 wrote:Se houver a necessidade apenas de alterar um arquivo .properties ou um .xml, podemos solicitar a alteração por e-mail e as coisas andam mais rápido, já que, uma vez que a própria equipe de infra do cliente efetuará a alteração e não haverá inspeção de pacote.

acho que isso acontecerá da mesma forma caso vocês venham a utilizar via anotações, como mencionei acima, qualquer anotação poderá ser redefinida via xml, pelo menos é assim como a especificação preza em maioria dos frameworks que conheço.

Thread.start() Membro desde: 25/08/2006 13:38:30 Mensagens: 37 Offline

Alguem viu alguma coisa sobre novos escopos (session, request, etc) de managed bean para o JSF 2.0???

faloww!!

felipe.regalgo wrote:Alguem viu alguma coisa sobre novos escopos (session, request, etc) de managed bean para o JSF 2.0???

o spring web flow tem um escopo de flow que é utilizado como meio para fluxo de transição de páginas, que evita trabalho braçal e uso do escopo de sessão. como o JSF 2.0 trata este problema?

acho que isso ficará por responsabilidade da WebBeans mesmo, com os seus @ConversationScoped beans

Virtual Machine Man Membro desde: 20/02/2008 12:32:59 Mensagens: 667 Offline

faelcavalcanti wrote:
uma outra desvantagem que vejo é nos merges no uso de controle de versão, em XML é um zaralho. o uso de anotações diminui este problema porque você está atualizando o artefato que você desenvolveu ou atualizou e fica mais próximo de saber o que será integrado em uma baseline, por exemplo.

Isso é verdade, já tivemos muito problema por causa de merges no xml.

Fabio Kung wrote:acho que isso ficará por responsabilidade da WebBeans mesmo, com os seus @ConversationScoped beans

legal. achei esta implementação no google code desta anotação.

não sabia deste recurso. fiquei mais feliz por saber. fábio, tens usado ele bastante. o que achasse de bom ou ruim?