JSF 2.0 - Early Draft Review 2

Muito bom Gilliard.

Boa Gillard, vou lá ler…!

boa iniciativa! vamos ver as mudanças…

"

definitivamente ?

"

definitivamente ?

heheh
Fui forte, né?
Mas estão reduzindo. Nem o web.xml vai precisar mais.

Quem vai dar o pontapé inicial na bagaça toda então ?

com os night build já é possivel criar os managed beans só com annotations?

é possível sim

@javax.faces.model.ManagedBean
@javax.faces.model.ManagedBeans
@javax.faces.model.ManagedProperty

Fora isso tem as anotações

@javax.faces.convert.FacesConvert
@javax.faces.validator.FacesValidator
@javax.faces.component.FacesComponent

Inclusive até já atualizei meu post comentando dos parametros dessas anotações

"

Eu acho vantagem.

Por exemplo, eu vou criar um Managed Bean, então eu cria a classe e a configuração dele está toda ali, junto. Acho uma vantagem isso. Sem contar que é mais facil criar uma linha com um @ na frente do que várias linhas com código XML.

Annotations tem lá algumas desvantagens, é verdade. Mas é muito melhor usar annotations do que XMeLeca.

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

"

marcosalex:

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.

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

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:

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.

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

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?

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:

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.

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

lgi2020:

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.

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:

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.

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

faloww!!

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

"

legal. achei esta implementação no google code desta anotação. :shock:
não sabia deste recurso. fiquei mais feliz por saber. fábio, tens usado ele bastante. o que achasse de bom ou ruim?

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.

marcosalex:

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:

marcosalex:

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).

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

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

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.

e como gera!

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:

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:

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).

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

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

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

você está falando do codebehind?

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.

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.

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.

"

jonataswingeter:

"(Nem pense usar um IceFaces ou RichFaces…aí mesmo vira uma bomba…
péssima qualidade na concepção destes frameworks de componentes). "

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.

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).

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)

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:

Alessandro Lazarotti:

jonataswingeter:

"(Nem pense usar um IceFaces ou RichFaces…aí mesmo vira uma bomba…
péssima qualidade na concepção destes frameworks de componentes). "

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.

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

Alessandro Lazarotti:

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).

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…

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!

"

Um tempo depois que saiu a implementação da EDR2 dei mais uma olhada na especificação e escrevi mais um post comentando sobre o novo escopo view que o JSF 2 vai suportar. Para explicar resumidamente, esse escopo é o tão sonhado maior que request e menor que session que o JSF 2 vai trazer “de série”. Quem quiser saber mais pode dar uma olhada no link acima.

Numa arquitetura que eu montei a uns anos atrás, existia um escopo de ação, que era um escopo que eu gerenciava internamente usando a session mas matando ele quando o usuario mudava de “tela”.

Sempre me perguntei porque diabos o java não tinha isso.

Com o JSF, ficou mais necessário ainda esse escopo. Agora parece que a solução vai aparecer seguindo o padrão do java: “devagar e sempre”.