Ajax Events as Behaviors

PrimeFaces provides various component callbacks to respond certains events, for example dialog has a server side closeListener and an attribute like onCloseUpdate. Similarly datatable has rowSelectListener with onRowSelectUpdate option. That is how we are implementing the callbacks, well… until now. The problem with current approach is limiting the page author to use partial processing since there is no onCloseProcess or onRowSelectProcess, also various options like global(flag to notify ajaxStatus), async, disabled are not available. I’ve received many feedback from users regarding this limitation and was planning to use JSF 2.0’s behavior APIs to solve this. After doing a proof of concept work, results are just fine.

Consider a tree component’s nodeSelect event, following is how we do it in 2.x;

    <p:tree nodeSelectListener="#{bean.handleSelect}" onNodeSelectUpdate="sth" ... >

And how it will be in 3.0;

    <p:tree ...>
        <p:ajax event="nodeSelect" listener="#{bean.handleSelect}" update="sth" />
    </p:tree>

Biggest advantage is since you use p:ajax, you can take advantage of handy options like global, async, disabled, oncomplete and we can avoid attribute hell.

Initial implementation of the new approach is at charts item select demo.

There are two important things to note, f:ajax is not supported instead p:ajax and this change breaks backward compatibility but the flexibility it brings justifies it.

About these ads

14 Responses to Ajax Events as Behaviors

  1. Daniel says:

    Sounds great!

    where can we get the list of events for each component?

  2. bitec says:

    Marvellous! A very good approach, which would reduce the quantity of attributes for components and increase flexibility. Frankly speaking I had problems with f:ajax, and try to use p:ajax usually and I would agree, that flexibility is more important, than backward compatibility. JSF as any JCP driven standard is awkward to innovations and enhancments and different ui frameworks should not restrict themselves to this area.
    It would be great to mark components attributes as deprecated, though don’t remember, whether the taglibs allow to do this as well as modern IDES – to display…

  3. All supported custom events will be documented in User’s Guide(Free of charge in 3.0).

  4. Oleg says:

    Really cool approach. I’m happy :-)

    Will be jQuery events supported too (as I proposed in the forum http://primefaces.prime.com.tr/forum/viewtopic.php?f=3&t=5497)? :-) Like this
    <p:tabView>

    <f:ajax listener="#{tabBean.onTabChange}" render="growl" event="tabsselect" />
    </p:tabView>

  5. jmrunge says:

    Sounds really great! Just one question: will be current events supported the old fashion way (nodeSelectListener=”#{bean.handleSelect}”) or will we have to rewrite our whole applications? :S

  6. Quoting;

    “There are two important things to note, f:ajax is not supported instead p:ajax and this change breaks backward compatibility but the flexibility it brings justifies it.”

  7. Ronald van Kuijk says:

    I like it from a technical/functional point of view, I “hate” it from a IDE point of view. You cannot get code completion now on which events are supported. More chance on runtime errors or disfunctional apps… Ah well, Probably just getting used to… Nice work (seriously :-))

  8. Hi Ronald, yes that is one downside but each component that support behaviors must implement ClientBehaviorHolder which has a method like getEventNames(), so it is up to IDEs to take advantage of this method for code completion. They can access this from the tag, I will ping friends from NetBeans about this.

  9. Ronald van Kuijk says:

    Ok, cool… never knew that (like I do not know many other things either :-)). I only hope IDE’s (my IDE is Eclipse btw, so I’ll try to investigate there) will dynamically load these kinds of things from the jar files containing the components… Thanks…

  10. jmrunge says:

    Cagatay,
    I was almost sure you will misundestand what I was trying to say… I undesrtood that f:ajax will be not suported, and p:ajax will have to be used insted, and I agree with that. What I ment is that this would be backwards compatible with the predefined events the components used to have, like “nodeSelectListener” and “onNodeSelectUpdate” or we will have to rewrite our applications removing this calls and replacing them with p:ajax. Was I clear? English is not my mother language… Sorry!

  11. Hi,

    As I’ve mentioned this change breaks backwards compatibility as it became a very hard task to support both methods both on the client side and the server side.

  12. As we are working on 3.0 which is a major release number, this is the best time to implement this. As after 3.0, things will be stable in PF.

  13. Daniel says:

    I think u should implement the atribute “for” on p:ajax. Im dealing with and the nested child must be a , so is child from .

  14. Daniel says:

    I think u should implement the atribute “for” on p:ajax. Im dealing with p:dialog and its nested child must be a h:form, the p:ajax is a child from h:form and not from p:dialog so i cant get onClose event to work.

Follow

Get every new post delivered to your Inbox.

Join 110 other followers

%d bloggers like this: