Home > JSF, JavaEE > f:ajax no JSF 2.0

f:ajax no JSF 2.0

Depois de muito tempo sem escrever estou eu aqui de novo falando de JSF 2.0

Neste post irei mostrar como está ficando o suporte a ajax do JSF 2. Já adianto que está ficando bem parecido com o Ajax4Jsf. Em outros posts eu já havia comentado sobre o suporte a ajax que a nova versão do jsf vai suportar. Mas agora vou falar do componente de tela para facilitar o uso, no outro post falei apenas da API JavaScript, que eu usei nesse exemplo.

O componente <f:ajax> parece o <a4j:support>. Essa nova tag pode ser usada tanto dentro de uma tag específica, tornando-a ajax, assim como fazemos com o <a4j:support> ou pode ser colocada em volta de vários componentes, tornando todos os componentes dentro dela ajax.

Por exemplo:

 
<h:panelGroup id="panelGroupX">
...
</h:panelGroup>
 
<h:outputText id="outputY" value="..."/>
 
<h:commandButton action="...">
    <f:ajax execute="@form" render="panelGroupX outputY"/>
</h:commandButton>

Nesse exemplo temos uma página como já estamos acostumados, até onde o novo componente aparece. Nesse caso a tag <f:ajax> está habilitando ajax no commandButton, e os dois principais atributos da tag são “execute” e “render”. O primeiro serve para informarmos o que será enviado ao servidor na nossa requisição ajax, e o segundo é como o “reRender” do ajax4jsf, e serve para informarmos o que será renderizado novamente. Ambos aceitam uma lista de ids, separados por espaço em branco, ou então os seguintes valores pré-definidos:

  • @this – o próprio componente que dispara a requisição ajax
  • @form – o formulário que envolve o componente @this
  • @all – a view inteira
  • @none – nenhum componente

Lembrando novamente que esses valores servem tanto para informar o que vai (execute) e o que volta (render) em uma requisição ajax.

Agora outro exemplo

 
<f:ajax event="onmouseover">
 
    <h:panelGroup id="panelGroupX">
    ...
    </h:panelGroup>
 
    <h:outputText id="outputY" value="..."/>
 
    <h:commandButton action="...">
        <f:ajax event="action" execute="@form" render="panelGroupX outputY"/>
    </h:commandButton>
 
</f:ajax>

Nesse caso a tag <f:ajax> envolve os demais componentes, fazendo com que tudo que está dentro dela passe a disparar eventos ajax. Cada tipo de componente possui um evento padrão que dispara a requisição ajax: um input dispara a requisição quando tem seu valor alterado e um botão ou link quando é clicado, por exemplo.

Porém nesse exemplo eu especifiquei que o evento padrão que executará o ajax para todos os componentes dentro da tag <f:ajax> é o “onmouseover”, mas como mostrado no commandButton eu posso sobrescrever os valores definidos na tag <f:ajax> de fora com uma tag dentro do próprio componente. Eu usei a propriedade “event“, mas poderia ter usado qualquer outra na tag ajax de fora, fornecendo assim um mesmo comportamente default para todos.

No último exemplo usei a propriedade “event“, que como visto no exemplo serve para dizer qual evento executará a requisição ajax. Essa propríedade suporta todos os eventos DOM e ainda “valueChange” para componentes de entrada de dados (ou mais especificamente um EditableValueHolder) e “action” para componentes de ação (um ActionSource).

A tag <f:ajax> suporta ainda os atributos:

  • listener – serve para fazer binding com um método que a seguinte assinatura “public void (javax.faces.event.AjaxBehaviorEvent event) throws javax.faces.event.AbortProcessingException“. Com isso podemos executar um código java quando um evento qualquer é disparado.
  • disabled – seria o equivalente ao rendered de um componente visual, se o valor definido aqui for true o suporta a ajax fica desabilitado.
  • immediate – igual o immediate dos componentes jsf comuns.
  • onevent – função js que será chamada quando o evento especificado for executado
  • onerror – função js que será chamada quando um erro ocorrer na requisição

Esse post foi curto por falta de tempo, mas novos posts virão em breve (assim espero ). Já estou com um exemplo pronto de implementação de conversation usando o suporte a escopos customizados do JSF 2.0, mas isso vai ter que ficar para o próximo post ;)

Gilliard Cordeiro JSF, JavaEE , ,

  1. Ezequiel
    May 11th, 2009 at 13:31 | #1

    Quando será que sai a versão final do JSF 2.0?

  2. May 11th, 2009 at 13:54 | #2

    Muito interessante Gilliard,

    Pelo visto eles estão “mixando” alguns frameworks/engines Ajax conhecidadas, como Ajax4jsf e Trinidad (acredito que outras) para definir a engine de ajax padrão da especificação, o que é algo realmente interessante, já que estes frameworks tem um boa maturidade nesse aspecto.

    Espero sinceramente que eles contemplem as funcionalidades básicas e essenciais encontradas noutras engines e que acertem “gaps” também comuns entre elas.

    Enfim, excelente post, parabéns.
    Abraços.

  3. May 12th, 2009 at 11:53 | #3

    Como eu havia prometido, post falando sobre escopo personalizado e implementação de conversation disponível.

  4. May 12th, 2009 at 11:58 | #4

    @Ezequiel, não sei quando sai a versão final da implementação, mas a versão final da especificação já foi enviada para o JCP, vamos ver se sai logo. Enquanto isso deve sair o beta1 da implementação em breve.

    @Rafael, obrigado. Espero também que as coisas fiquem o mais usáveis “de série” possível, e para casos onde outras soluções continuarão sendo usadas que tudo fique o mais integrável possível também.

  5. Wagner Borges
    May 28th, 2009 at 08:59 | #5

    Gilliard, primeiramente parabéns pelo belo post. Muito bom mesmo.

    Agora ficou uma dúvida. Quando você fala da passagem de paramentros e URL’s amigaveis. Isso já não era possivel antes? a diferença está somente no fato de ser via GET? por que antes eu já tinha isso: .

    desculpa a ignorância. Um abraço.

  6. June 17th, 2009 at 16:53 | #6

    @Wagner Borges
    Desculpa a demora na resposta mas é que eu passei por uns probleminhas de manutenção no blog. Agora com relação ao que você disse, realmente dá para passar parâmetros pela URL e pegar isso em outro lugar. O que acontece é que a gente acaba passando String como parâmetro… e como eu já falei algumas vezes aqui no blog, a menos que você de fato queira passar uma String como parâmetro(coisa que raramente acontece), a pior coisa que tem é você ficar trabalhando com String dentro do JSF.

    O bacana do JSF é essa possibilidade que ele dá de trabalhar o OO, transformando as Strings que são trafegadas pelo HTTP em objetos dos tipos corretos. Com esse novo a gente pode descrutar de todo o poder do JSF passando parâmetros via GET.

    Você pode ver mais nesse outro post
    http://blog.gilliard.eti.br/2009/05/urls-amigaveis-no-jsf-2

    E sempre tem uma coisa que a gente não sabe… ignorância é não querer aprender ;)

  7. January 3rd, 2010 at 15:59 | #7

    Gilliard, estou montado um curso sobre JSF 2.0 que irei ministrar em um curso de verão de uma faculdade e gostaria de saber se posso utilizar alguns tutoriais aqui mostrados, irei citar que foram tirados do seu site e assim q terminar posso disponibilizar uma cópia para postar aqui. este curso está sendo embasado em uma monografia minha de Pos-graduação. Fico no aguardo de sua resposta desde já agradeço.

  8. January 7th, 2010 at 08:39 | #8

    Olá Daniel, sinta-se a vontade para usar o material. Como irá citar a fonte não há problema algum.
    Bom curso e desculpe pela demora em responder, mas sabe como são as férias né… estava off-line.

  1. May 11th, 2009 at 10:43 | #1