As Novidades do JSF 2.0

Transcrição

1 artigo As Novidades do JSF 2.0 Conheça a nova versão do JSF que traz inúmeras vantagens em relação ao seu antecessor. O JSF é hoje a principal ferramenta no mundoj para desenvolvimento Web, principalmente por fazer parte nativamente da plataforma Java EE. Porém essa tecnologia sempre teve a fama de ser trabalhosa, com muitas configurações em XML e não possuir recursos importantes como suporte à AJAX. A versão 2.0 traz melhorias significativas para o JSF, mais facilidades e recursos novos. Este artigo apresenta essas novidades para o programador JSF. QSJNFJSB WFSTÍP EP +BWB4FSWFS 'BDFT GPJ MBOÎBEB FN " ÞMUJNB WFSTÍP EB TÏSJF Y Ï B MBOÎBEB FN F RVF GB[ QBSUF da especificação do Java EE 5. Por ser uma tecnologia oficial na plataforma Java, o JSF logo alcançou grande sucesso. Além de ser parte do Java EE, seu modelo de desenvolvimento baseado em componentes atraiu bastante atenção por facilitar o desenvolvimento de aplicações complexas baseadas em muitas telas com formulários. A Mas o JSF também era bastante criticado por ter muitas configurações, muitos XMLs, pela falta de suporte a AJAX, pela complexidade de uso, entre outras deficiências. Alguns frameworks tentaram melhorar alguns pontos, sendo o mais famoso o JBoss Seam. Sérgio Lopes (sergio.lopes@caelum.com.br) é desenvolvedor Java desde 2002 e bacharelando na Universidade de São Paulo. Possui as certificações SCJP e SCEA5 e é moderador do GUJ, palestrante em diversos eventos e instrutor e desenvolvedor na Caelum Ensino e Inovação $PN P MBOÎBNFOUP EB WFSTÍP EP +4' FN NFBEPT EF NVJUBT novidades foram incorporadas com objetivo de simplificar o desenvolvinfoup F BVNFOUBS B QSPEVUJWJEBEF EP QSPHSBNBEPS 0 +4' GB[ QBSUF EP recém-lançado Java EE 6 (vide artigo nesta edição) e, com isso, integra-se também a outros recursos da plataforma, como o CDI (também com artigo nesta edição). Neste artigo, direcionado a desenvolvedores JSF, veremos as principais OPWJEBEFT EB OPWB FTQFDJmDBÎÍP 1BSB UFTUBS UPEPT PT FYFNQMPT VTBmos a implementação de referência do JSF provida pela Sun (Mojarra) cujo link está disponibilizado nas referências do artigo.

2 Facilidade de configuração e novos escopos Até a versão anterior do JSF, para configurar o bean que seria gerenciado e manipulado pelo JSF, o Managed Bean, era necessário adicionar algu- package br.com.caelum.jsf2; import public class AgendaHandler { } gistrada como um managed bean do projeto. Nessa anotação pode ser especificado, opcionalmente, o atributo name, utilizado para definir um nome para o acesso do managed bean na Expression Language. Caso nenhum seja especificado, é assumido que o nome do managed bean é o nome da classe convertendo a primeira letra para minúscula. No - tionscoped. Se o managed bean não for anotado com nenhuma delas, o está entre os escopos de request e de sessão. É um escopo que sobrevive a vários requests que interajam com a mesma tela do JSF. Há também Com ele, é possível obter um escopo com duração até o request seguinte, útil para recuperar objetos logo depois de um evento ou um redirecionamento. Há ainda a possibilidade de se criar escopos personalizados com Mas tanto o Mojarra quanto o MyFaces implementam a ideia. É possível ao invés das do JSF. A vantagem é integrar seus managed beans do JSF a toda a infraestrutura do Java EE 6. Usaríamos então a do CDI javax.enterprise.context, por exemplo. E, por ser um Inject para injeção de dependências. Mas nem todas as anota- exemplo, não existe no CDI. Para saber mais sobre o CDI, consulte o artigo correspondente nesta mesma edição da Mundoj. Facelets como view padrão e composite components A primeira versão do JSF definiu que a view deveria ser declarada usando JSPs com taglibs especiais do JSF. Mas sempre houve muitas críticas ao uso do JSP como view do JSF. Era difícil integrar taglibs que não fossem de JSF, o ciclo de vida do processamento do JSF se confundia com o processamento do JSP, a performance não era adequada, as views eram pouco reaproveitáveis e JSPs nunca foram uma maneira muito adequada para se declarar uma árvore de componentes. Logo começaram a surgir tecnologias alternativas para views extensão para outros motores de visualização e transforma o Facelets na alternativa oficial, não exigindo nenhuma configuração extra para usá-lo. Mais que isso, o JSP, embora ainda suportado, passa a ser desencorajado e Facelets, agora, é a view padrão para JSF. Com Facelets, as views são escritas em XHTML e trazem muitos benefícios. O tempo de compilação é menor, a performance de renderização é melhor e, o mais importante, possui um mecanismo bastante robusto para se criar composições, templates e novos com um formulário e um campo de texto. <title>olá Mundo!</title> <h:body bgcolor= white > Nome: <h:inputtext/> Uma das maiores facilidades do Facelets é o uso de templates. É possível definir uma página com uma estrutura padrão e reaproveitável, e depois definir páginas específicas que preencham o template com informações próprias. A Listagem 3 mostra um exemplo de template e o uso dele em uma página específica, onde temos no template. xhtml o uso do <ui:insert> que vai ser trocado pelo valor definido no <ui:define> do agenda.xhtml. Outro recurso interessante do Facelets é a facilidade na criação de componentes reutilizáveis, os chamados trabalho descomunal, envolvendo implementações de várias classes e configurações, sendo uma tarefa de grande complexidade. Imagine uma listagem qualquer que precise ser reutilizada em vários pontos da aplicação, mas que precisa receber os objetos a serem listados em cada situação. Uma alternativa era criar um componente que recebia uma lista como argumento e renderizava a tabela para nós. Com Facelets, usamos as tags <composite:interface> e <composite:implementation> para definir o novo componente. Ele será definido dentro de um arquivo XHTML em uma pasta dentro de /resources com o nome do namespace que desejamos definir. Por exemplo, se quisermos uma tag <caelum:tabela>, criamos o arquivo tabela.xhtml na pasta /resources/caelum/. No ar- 47

3 quivo tabela.xhtml, usamos a tag <composite:interface> para definir o que os usuários do componente precisam saber (atributos, facets, eventos) e a <composite:implementation> para implementar o código do componente. A Listagem 4 apresenta um esboço do componente de tabela recebendo um argumento com a lista de objetos. A tabela. xhtml faz isso através da tag <composite:attribute> declarado dentro de <composite:interface>. A listausuarios.xhtml mostra um exemplo de uso do componente através da tag <caelum:tabela lista= >. Repare na declaração do namespace para o uso do componente criado. O uso de Facelets abre muitas possibilidades para o desenvolvedor JSF. Os exemplos deste artigo mostram as ideias principais, mas há ainda outros recursos, como tags para debug, utilização de tags html etc. Listagem 3. Uso de templates. template.xhtml <title> <ui:insert name= titulo >Titulo padrão</ui:insert> </title> <h:body bgcolor= white > <ui:insert name= corpo >Texto padrão</ui:insert> agenda.xhtml <ui:composition template= /template.xhtml > <ui:define name= titulo >Agenda</ui:define> <ui:define name= corpo > <h:form id= helloform > <h:panelgrid columns= 2 > Nome: <h:inputtext/> Telefone: <h:inputtext/> <h:commandbutton value= Cadastrar /> </h:panelgrid> </h:form> </ui:define> </ui:composition> Suporte a AJAX Qualquer aplicação Web moderna, em especial as que necessitam de muita interação com usuário, usa AJAX para a melhorar a responsividade da usar AJAX com JSF significava usar alguma biblioteca não padronizada com extensões proprietárias que possibilitavam o uso dessa tecnologia. Várias bibliotecas surgiram, como o Ajax4jsf, o IceFaces, entre outras. O grande problema era a falta de padronização, a incompatibilidade entre as soluções e a necessidade de instalação e configuração de uma biblioteca extra. A de uma forma bastante extensível e reaproveitável. A especificação começa Listagem 4. Uso de composite components. xmlns:h= xmlns:composite= > <title>não será apresentado ao renderizar o componente</title> <h:body> <composite:interface> <composite:attribute name= lista /> </composite:interface> <composite:implementation> <h:datatable items= #{cc.attrs.lista} var= obj > <h:column>... </h:column> </h:datatable> </composite:implementation> listausuarios.xhtml xmlns:h= xmlns:greet= > <title>lista de usuários</title> <h:body> <caelum:tabela lista= #{meumanagedbean.usuarios} /> definindo uma biblioteca JavaScript, cuja referência está no final do artigo, acessível nas páginas e que integra todas as chamadas do cliente ao ciclo de vida do JSF. É possível escrever as chamadas direto em código JavaScript ou, para facilitar, usar a tag <f:ajax> que monta a invocação certa para nós. A Listagem 5 mostra as duas possibilidades de se invocar um método via AJAX quando o usuário clicar no <h:commandbutton>. Neste exemplo, invocamos um método salvar no botão e renderizamos novamente uma parte da tela com o componente cujo id é igual a tabela. <!-- Tabela que queremos renderizar ao clicar no botão --> <h:datatable id= tabela...>... </h:datatable> <!-- Usando a API JavaScript diretamente --> <h:commandbutton id= meubotao value= Salvar actionlistener= #{meumanagedbean.salvar} onclick= jsf.ajax.request(this,event, {execute: meubotao, render: tabela }); /> <!-- Usando a tag de ajax --> <h:commandbutton actionlistener= #{meumanagedbean.salvar} > <f:ajax render= tabela /> </h:commandbutton> 48

4 Navegação implícita e condicional Nos esforços de diminuir a quantidade de configuração necessária, o JSF gurações de navegação necessárias na versão anterior. Ao executar uma action, se nenhuma regra de navegação bater com o outcome devolvido, o JSF buscará uma página com o nome daquele outcome. Por exemplo, se o botão devolver o outcome "inicial" (como na Listagem 6) e nenhuma regra de validação existir, o JSF procurará uma página inicial.xhtml. Se ela existir, a navegação será feita implicitamente, sem necessidade de configuração Listagem 6. Navegação implícita. <!-- Botão que redireciona para inicial.xhtml --> <h:commandbutton value= Voltar action= inicial /> adicionar condições com a tag <if> na configuração. Ao configurar uma <navigation-rule> no XML, é possível apontar um resultado booleano que indica se aquela regra deve ser executada ou não. Na Listagem 7, temos um exemplo do uso da tag invocando um método de um managed bean que retorna boolean. Listagem 7. Navegação condicional. <navigation-rule> <from-view-id>/pagina1.xhtml</from-view-id> <navigation-case> <from-outcome>acao</from-outcome> <to-view-id>/pagina2.xhtml</to-view-id> <if>#{meumanagedbean.devonavegar}</if> </navigation-case> </navigation-rule> Validação e Bean Validation ção de dados na plataforma Java. É baseada nas ideias do Hibernate Validator (hoje sua implementação de referência) e outros frameworks de validação. Com a Bean Validation é possível usar anotações diretamente nas classes de modelo indicando a validação que deve ser feita para cada atributo. Há a extensão das anotações de validação pela própria aplicação. Basta anotar as classes de modelo e o container cuida da validação. A grande vantagem da Bean Validation é ela ser integrada à plataforma Java implementação da Bean Validation, basta anotar as classes de modelo e tudo será automaticamente validado na fase de validação do JSF, inclusive com a exibição das mensagens de erro nos componentes apropriados. <f:validaterequired/> para campos obrigatórios e <f:validateregexp /> para validações com expressões regulares. Suporte a GET Uma crítica constante ao JSF é seu fraco suporte a GET e sua característica de post back que trata os requests quase sempre como POST. Não suportar adequadamente o uso de GET cria dificuldades no uso de bookmarks para páginas da aplicação e prejudica quando é necessário SEO (Search Engine Optimization). view parameters que permitem receber parâmetros pela URL do GET e mapeá-los para propriedades de managed beans, como mostra a Listagem 8. Além disso, há todo um ciclo de vida associado a requests GET que permite fazer praticamente tudo que se fazia via POST. Listagem 8. View parameters. <!-- Recebo?parametro=bla e seto a propriedade no bean --> <f:metadata> <f:viewparam name= parametro value= #{meubean.propriedade} /> </f:metadata> ponentes de navegação além dos conhecidos <h:commandbutton> e <h:commandlink> que usam POST. Os novos componentes são o <h:button> e o <h:link> que usufruem de toda a infraestrutura de chamado de navegação preemptiva, o outcome desses componentes é resolvido durante a renderização da página. Isso faz com que o HTML gerado possua o link final correto direto para a página linkada sem que o desenvolvedor precise escrever o link explicitamente, mas possa usar os mecanismos de navegação do JSF. vegação e passando um parâmetro. A URL será gerada direto no HTML e o request será feito via GET, permitindo ao usuário adicioná-la em seus bookmarks. <h:link outcome= visualiza > <f:param name= tag value= #{meubean.tag} /> </h:link> Outras novidades a criação do conceito de project stages. É possível indicar para a implementação do JSF o momento em que estamos no uso da aplicação e ela pode ter comportamentos diferentes. Por exemplo, é possível indicar que estamos em Development e a implementação exibir mais detalhes nos erros. Ou indicar que estamos em Production e a implementação compactar todo o código HTML e JavaScript para melhorar performance (o Mojarra hoje já faz isso). E, além dessas, temos as opções SystemTest e UnitTest e a escolha do stage pode ser feita através do context-param javax.faces. PROJECT_STAGE. Houve também mudança na hora de salvar o estado dos componentes 49

5 "SUJHP t $%* o "T /PWJEBEFT EP +4' QBSB VTBS NFOPT FTQBÎP "OUFT UPEB B ÈSWPSF FSB TBMWB F TFSJBMJ[BEB BHPSB todo componente tem um estado padrão associado e apenas as diferenças do estado em relação a esse padrão são salvas, diminuindo o tamanho do view state, algo excelente para a escalabilidade das aplicações JSF. Outra adição foi o suporte a SystemEvents aos tipos de eventos suportados, além dos já existentes PhaseEvents e FacesEvents. Os SystemEvents permitem observar a ocorrência de outros tipos de eventos antes não detectáveis pela API do JSF. É possível, por exemplo, observar eventos internos que um componente JSF deseje expor e, através da tag <f:event>, registrar um listener para eventos específicos. E o mecanismo extensível permite até que o desenvolvedor crie seus próprios eventos que podem ser observados de outros pontos da aplicação. Além dessas, muitas outras novas funcionalidades foram adicionadas, tendo como alvo desenvolvedores de componentes e extensibilidade de pontos mais internos do JSF. Referências t &TQFDJmDBÎÍP +4' IUUQ KDQ PSH FO KTS EFUBJM JE t *NQMFNFOUBÎÍP EF SFGFSÐODJB EP +4' t &TQFDJmDBÎÍP +BWB4DSJQU EP "KBY OP +4' t 3FTVNP EBT OPWJEBEFT EP +4' QPS "OEZ 4DIXBSU[ t &TQFDJmDBÎÍP #FBO 7BMJEBUJPO IUUQ KDQ PSH FO KTS EFUBJM JE t.bjt TPCSF #FBO 7BMJEBUJPO Considerações finais 0 +4' KÈ FTUÈ IPKF NBEVSP P TVmDJFOUF QBSB TFS VTBEP FN QSPEVÎÍP BUSBWÏT EP.PKBSSB B JNQMFNFOUBÎÍP EP.Z'BDFT UFWF TVB WFSTÍP CFUB MBOÎBEB FN GFWFSFJSP EF NBT PVUSBT CJCMJPUFDBT EF DPNQPOFOUFT FYJTUFOUFT BJOEB FTUÍP TFOEP BEBQUBEBT QBSB P +4' 0 +#PTT 3JDI'BDFT BJOEB FN EFTFOWPMWJNFOUP TFSÈ UPEP CBTFBEP FN +4' B WFSTÍP BUVBM FTUÈ FN CFUB F BQFOBT DPN BEBQUBÎÜFT QBSB SPEBS DPN +4' 0 *DF'BDFT DPN TVQPSUF BP OPWP +4' FTUÈ FN "MQIB F MPHP EFWFSÈ TFS lançado. Essa é a mesma situação do MyFaces Trinidad. " OPWB FTQFDJmDBÎÍP EP +4' Ï VN JNQPSUBOUF QBTTP QBSB B FWPMVÎÍP dessa tecnologia. Foram adicionados importantes novos recursos e muita coisa foi simplificada. É uma versão focada em uma maior produtividade e facilidade de integração com outras tecnologias. Junto com o lançamento do Java EE 6 (coberto nesta edição da Mundoj) promete HSBOEFT NFMIPSJBT QBSB P EFTFOWPMWJNFOUP 8FC FN +BWB t