O tempo foi curto, e não deu pra explorar muito o exemplo, mas estou disponibilizando agora a apresentação e o projeto de exemplo usando JSF 2. O exemplo foi feito usando Java 6 e tomcat 6.

Alguns pontos que eu procurei mostrar no exemplo foram:

API AJAX do JSF 2.0

No código do exemplo podemos ver trechos de código como este:

...
<h:commandButton value="Salvar" action="#{estadoBean.salvar}"
onclick="return facesAjaxRequest(this, event, {inputs: 'formEstado', render: 'formEstado:listaEstados'})"/>
...

onde eu criei essa função js chamada facesAjaxRequest que encapsula a simples chamada ajax do jsf 2 que seria assim:

jsf.ajax.request(element, event, options);

Essa funçao recebe o elemento que está disparando a ação (normalmente this), o evento e um mapa de parâmetros. Nesse mapa existem duas entradas: execute e render. No render, especificamos, separados pos espaços em branco, os clientIds dos componentes que serão renderizados novamente, e no execute passamos os valores a serem enviados ao server nessa requisição ajax.

No exemplo usei a função facesAjaxRequest para montar dinamicamente a lista que vai no parâmetro execute, por isso este parâmetro não aparece no primeiro exemplo mostrado. Com essa função, podemos ainda passar o id de qualquer elemento html pelo atributo inputs do mapa que todos os inputs e selects que estiverem abaixo desse elemento será enviado para o server. Na tela de cadastro de cidades fiz uma espécie de ajaxRegion usando essa forma bem simples.

Isso tudo porque o JSF 2 não tem algo tão fácil de usar como os componentes da biblioteca ajax4jsf. A idéia dessa biblioteca de ajax de jsf 2 não é deixar tudo mastigadinho, e sim prover uma infraestrutura básica uso padronizado de js nos componentes, eliminando ou diminuindo assim as incompatibilidades entre as bibliotecas de componentes disponíveis.

Para quem chegou a usar as funções js do Facelets 1.2, que nem chegou a ser continuado, e que eu mostrei num artigo que escrevi pra MundoJava há muito tempo, o funcionamento é quase o mesmo, só mudando praticamente o nome das funções js e a forma como os dados eram enviados ao server.

Facelets 2

Como já foi dito por aí, agora o JSF já vem por default com o Facelets 2 habilitado, não sendo necessário colocar nenhuma configuração para utilizálo. Inclusive no exemplo disponível para download, nem existe o arquivo faces-config.xml, pois fiz tudo por anotações e o Facelets já vem pronto pra uso. Mas é claro que ele continua sendo utilizado para as regras de navegação.

Criação de componentes com Facelets 2

Com facelets 2, a criação de componentes será algo mais “formal” do que fazemos com facelets hoje em dia. Isso graças a presença de uma definição do componente como esse:

...
<composite:interface name="beanSimples">
    <composite:attribute name="bean" required="true">
        <composite:attribute name="descricao" type="String" required="true"/>
    </composite:attribute>
</composite:interface>
 
<composite:implementation>
    Descrição: <h:inputText id="descricao" value="#{compositeComponent.attrs.bean.descricao}"/>
</composite:implementation>
 
...

O componete possui a interface e a implementação. Na interface podemos colocar os parâmetros que serão recebidos, como no exemplo onde eu preciso passar um objeto que eu chamei de “bean” e esse bean tem que ter um atributo do tipo String chamado descrição.

É possível ainda passar atributos que representam ações, o que não é possível hoje em dia. Além disso não é necessário nenhum arquivo para configurar o nosso componente customizado, tudo é feito através de convenção. Basta colocar o componente em uma pasta dentro do resources do jsf que ele já fica publicado e acessível por uma uri default. Mas se quisermos colocar uma uri específica é só indicar através de um arquivo de configuração.

SelectItems

Finalmente podemos usar o componente f:selectItems sem ter que criar uma lista ou array de SelectItem. Agora podemos usar diretamente nossos objetos do modelo como podemos fazer usando outros componentes de selectItems como o do Seam.

<h:selectOneMenu value="#{cidadeBean.cidade.estado}">
    <f:selectItems value="#{estadoBean.estados}" var="estado" itemLabel="#{estado.descricao}" itemValue="#{estado}"/>
</h:selectOneMenu>

Finalizando

O exemplo disponível é bem simples, mas procurei mostrar nele o uso de coisas simples, como as mencionadas acima, e também proporcionar para quem ainda não teve a disposição de começar a testar que já tenha um ponto de partida. Olhando o código fonte podemos ver funcionando também as novas tags para escrever css e js, e explorar a parte de localização de recursos, que é inclusive o que torna a criação de componentes tão simples.

Espero que esse post e os materiais relacionados sejam de utilidade, e caso você encontre algum erro no material disponível me avise comentando aqui

Primeiramente, vou me basear nas diferenças entre as reviews 1 e 2, mas isso não significa que o que vou falar aqui é inédito pois podemos ver na net diversos post comentando o que vem por aí. E também ainda não li tudo, a idéia é compartilhar o que mais me chamou a atenção nesse primeiro contato.

FacesContext

Sem dúvida essa é uma das classes que mais manipulamos no JSF, e nela temos algumas funcionalidades novas interessantes:

• getCurrentPhaseId() – Disponível desde a EDR1, devolve um PhaseId. Pode ser bem útil para fazermos algumas coisas só depois de uma dedeterminada fase.
• getExecutePhaseClientIds() - Devolve uma List<String>. Guarda uma lista com os client ids dos componentes que serão processados na requisição atual. Isso porque o JSF2 tem nativamente o suporte à ajax, e submissão parcial da página.
• getPartialResponseWriter() - Devolve o ResponseWriter para os componentes de uma renderização parcial.
• getRenderPhaseClientIds() - Devolve uma List<String> contendo os client ids dos componentes que serão renderizados em uma renderização parcial.
• isAjaxRequest() - devolve um boolean dizendo se a requisição é ajax (auto explicativa né )
• isExecuteNone() - retorna true se for uma submissão parcial mas nenhum componente precisará ser processado. Seria como dar apenas um reRender usando o ajax4jsf mas sem mandar executar nada.
• isPostback() - método "atalho" para ResponseStateManager.isPostback(FacesContext).
• isRenderAll() - Retorna true se for uma requisição ajax, isRenderNone() retornar falso, e getRenderPhaseClientIds() retornar uma lista vazia.
• isRenderNone() - Retorna true caso for para executar uma renderização parcial, mas a lista de componentes a renderizar for vazia. Imagine uma requisição ajax que só envia dados ao servidor.

Para os métodos get dessa lista, também tem os respectivos set.

Annotations

Uma coisa que todo mundo esperava está disponível no EDR2, que é a possibilidade de anotar nossos managed beans com @ManagedBean, @FacesValidator, @FacesConverter e @FacesComponent entre outros.

Para quem já está habituado com o Seam vai se sentir bem a vontade, pois as anotações seguem o mesmo estilo.

Apesar de no começo parecer estranho esse prefixo "Faces" em todas essas anotações, fica útil para não confundir com as interfaces com o mesmo nome. Sem isso (no Seam é assim), como importamos a anotação e a interface com o mesmo nome, uma das duas tem que ficar com o nome totalmente especificado. Não que seja problema, mas com esse prefixo fica mais "limpinho".

@ManagedBean

• name - nome do managed bean
• scope- escopo. O que não pareceu tão legal é que a gente passa uma String ("request", "session" ou "application"), quando seria mais bacana uma Enum como o Seam faz. O valor default é "none".
• eager - se for true, o managed bean será startado junto com a aplicação, e o "escope" passado será ignorado, e o managed bean será do escopo application. Se for false, fica como é hoje (lazy). O default é false.

@RequestScoped, @SessionScoped, @ApplicationScoped, @NoneScoped, @ViewScoped, @CustomScoped

• Cada uma das anotações representando seus respectivos escopos

@FacesConverter

• value - string que representa o converter-id do conversor
• forClass - passamos o java.lang.Class da classe que queremos registrar o conversor na forma de converter-for-class

@FacesValidator

• value - string que representa o validator-id do validador

@FacesComponent

• value - string que representa o component-type do UIComponente

Facelets 2

O outro assunto que de cara me interessou foi a integração do JSF com o Facelets, pois já uso Facelets há um bom tempo e nem me imagino fazendo uma aplicação em JSF sem ele. Tanto que até escrevi uma matéria pra a MundoJava sobre Facelets e as novidades do JSF 1.2. Na época eu comentei sobre a versão 1.2 do Facelets que nunca chegou a sair, talvez porque o pessoal passou a investir no JSFTemplating ou quem sabe viram que compensaria partir logo para um 2.0. Mas no Facelets 1.2 já podíamos ver o que provavelmente foi a base da API de Ajax para o JSF2.

No JSF2 temos o chamado PDL (Page Declaration Language), que é uma abstração para os mecanismos de definição de páginas disponíveis para o JSF, que até agora são JSP e Facelets. Porém se a gente der uma espiadinha no projeto JSFTemplating, podemos ver que existe a possibilidade de usarmos outras coisas, como Groovy por exemplo. Então é bem possível que vejamos coisas parecidas para o JSF2. Só para concluir a idéia, já é possivel usar Groovy em vez de xhtml para construir telas com Facelets, usando Gracelets. É bem bacana e eu já fiz uns testes que depois vou postar aqui também. Mas vamos voltar ao assunto.

Na EDR2 é explicado como será mantida a compatibilidade retroativa com as aplicações que usam Facelets. Basicamente será procurando dentro das classes da nossa aplicação ou das dependencias dela se existe alguma dependencia de classes do pacote com.sun.facelets e/ou dos seus subpacotes. Se houver, o Facelets embarcado no JSF não vai rodar, e as coisas vão continuar como estão, onde quem roda é o facelets que está no jar da nossa aplicação. Agora se não houver dependencia com as classes do Facelets atual, o Facelets2 entra em ação.

Composition Component com JSF/Facelets 2

Primeiramente, seria interessante dar uma olhada no suporte a recursos do JSF2 para entendermos melhor como tudo vai funcionar. Vou seguir o exemplo da documentação para facilitar.

Um composition component vai ser definifo usando o suporte a resources do JSF2. Imagine que o source do nosso componente é o foo.xhtml que está dentro da pasta ezcomp que por sua vez fica dentro da pasta de resources do JSF. Para usarmos esse componente nao precisamos mais de um arquivo taglib.xml, bastara chamarmos assim:

1
2
3
4
5
6
7
8
9
10
11
12

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
 <html xmlns="http://www.w3.org/1999/xhtml"
 xmlns:h="http://java.sun.com/jsf/html"
 xmlns:f="http://java.sun.com/jsf/core"
 xmlns:ui="http://java.sun.com/jsf/facelets"
 xmlns:ez="http://java.sun.com/jsf/composite/ezcomp">
 
   ...
   <ez:foo />
   ...
</html>

Como podemos ver nossos componentes ficam automaticamente visíveis usando o padrão http://java.sun.com/jsf/composite/<composite-library-name> onde <composite-library-name> é o nome da nossa pasta dentro do resources do JSF. E cada xhtml dentro dessa pasta pode ser acessado como um componente. Vimos aqui um bom exemplo de CoC no JSF2. Agora se quisermos usar um padrão diferente de nomenclatura para nossos componentes, basta usar o bom e velho arquivo de configuração de taglibs do facelets.

Agora ainda seguindo o exemplo disponível na versão snapshot (e provavelmente será a mesma do EDR2), vamos ver como fica o código de um componente definido em um arquivo chamado loginPanel.xhtml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:h="http://java.sun.com/jsf/html"
      xmlns:f="http://java.sun.com/jsf/core"
      xmlns:ui="http://java.sun.com/jsf/facelets"
      xmlns:composite="http://java.sun.com/jsf/composite">
<head>
<title>Not present in rendered output</title>
</head>
<body>
 
<composite:interface name="loginPanel"
                     displayName="Very Simple Login Panel"
                     preferred="true"
                     expert="false"
                     shortDescription="An illustration of the composite component feature">
 
  <composite:attribute name="model" required="true">
 
    <composite:attribute name="loginAction" required="true">
      <composite:deferred-method>
        <composite:method-signature>
                    java.lang.Object action()
        </composite:method-signature>
      </composite:deferred-method>
     </composite:attribute>
 
   </composite:attribute>
 
 
  <composite:editableValueHolder name="username" />
  <composite:actionSource name="loginEvent" />
  <composite:actionSource name="cancelEvent" />
  <composite:actionSource name="allEvents" targets="loginEvent,cancelEvent" />
 
  <composite:facet name="header" />
 
</composite:interface>
 
<composite:implementation>
 
<table border="1">
  <thead>
    <tr>
      <th>
     <composite:insertFacet name="header" />
      </th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>
      <p>
         <h:inputText id="username" />
      </p>
      <p>
	<h:commandButton id="loginEvent" value="Login" action="#{compositeComponent.attributes.model.loginAction}">
 
	</h:commandButton>
	<h:commandButton id="cancelEvent" value="Cancel" action="cancel">
	</h:commandButton>
      </p>
      </td>
    </tr>
    <tr>
      <td>
     <p>This is the login panel footer</p>
     <composite:insertChildren />
      </td>
    </tr>
  </tbody>
</table>
</composite:implementation>
</body>
</html>

Coloquei o código todo, mas o mais importante é da linha 12 até a linha 41, que é onde definimos as características do nosso componente. Isso deve facilitar que ferramentas deem suporte aos nossos componentes, e também a quem for usar esses componentes, pois damos mais informações a respeito das propriedades que ele precisa. A documentação diz que em muitos casos será possível construir componentes sem prover essas informações, deixando mais parecido com o que é hoje, mas diz também que falta definir um limite de até onde pode ser feito um componente sem especificar esse "contrato de uso".

Uma coisa interessante que pode ser vista nesse exemplo é a exigencia de um método chamado loginAction com uma assinatura específica dentro do objeto que for passado no atributo model.

O código que usa esse componente pode ser visto a seguir

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:h="http://java.sun.com/jsf/html"
      xmlns:f="http://java.sun.com/jsf/core"
      xmlns:ui="http://java.sun.com/jsf/facelets"
      xmlns:ez="http://java.sun.com/jsf/composite/ezcomp">
<h:head>
<title>The Simplest EZComp Demo That Could Possibly Work</title>
</h:head>
<h:body>
<p>Login Panel Component</p>
  <ui:debug hotkey="p" rendered="true"/>
<h:form>
  <div id="compositeComponent" class="grayBox" style="border: 1px solid #090;">
 
    <ez:loginPanel id="loginPanelInConsumingPage" model="#{bean}">
 
      <f:valueChangeListener for="username" binding="#{bean.useridValueChangeListener}" />
      <f:actionListener for="loginEvent" binding="#{bean.loginEventListener}" />
      <f:actionListener for="cancelEvent" binding="#{bean.cancelEventListener}" />
      <f:actionListener for="allEvents" binding="#{bean.allEventsListener}" />
 
      <f:facet name="header">
         <h:panelGroup id="headerFacetInConsumingPage">
          <h:outputText value="this is the header facet in the consuming page" />
         </h:panelGroup>
      </f:facet>
      <h:outputText id="childInConsumingPage" value="this is a child component in the consuming page" />
    </ez:loginPanel>
  </div>
<p><h:commandButton value="reload" /></p>
</h:form>
</h:body>
</html>

Nesse exemplo pode reparar da linha 18 a 21 que usamos os composite:actionSource definidos no componente como ganchos para pendurar nossos listeners.

Só lembrando que esses exemplos são em cima da EDR2 do JSF2, então tudo que foi visto aqui pode não ser igual ao que vai estar na versão final.