wood burning stoves*
The moose likes JSF and the fly likes A programmatically added AjaxBehaviour into a CommandLink doesn't work Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Java » JSF
Bookmark "A programmatically added AjaxBehaviour into a CommandLink doesn Watch "A programmatically added AjaxBehaviour into a CommandLink doesn New topic
Author

A programmatically added AjaxBehaviour into a CommandLink doesn't work

bouhmid Feki
Greenhorn

Joined: Apr 03, 2013
Posts: 6
I'm adding a an AjaxBehaviour to a commandLink (both are programmatically created). I've tried two ways for adding the AjaxBehaviour but none of them worked. However, the commandLink is successefully added and i can see it on the view.

Here is my code for adding the commandLink and the AjaxBehaviour :



for the first method for adding the Ajax behaviour i've used an Ajax Listener handler managed bean method, the following :




for the second method i created a new class :




Can someone tell me what is wrong in both of these two ways?. Cheers!
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15952
    
  19

Welcome to the JavaRanch, Bouhmid!

My first question when I see code like this is to ask the following question: Why are you doing this in Java code instead of using a View Definition Language template definition?


Customer surveys are for companies who didn't pay proper attention to begin with.
bouhmid Feki
Greenhorn

Joined: Apr 03, 2013
Posts: 6
Tim Holloway wrote:Welcome to the JavaRanch, Bouhmid!

My first question when I see code like this is to ask the following question: Why are you doing this in Java code instead of using a View Definition Language template definition?



Thanks Tim,
Actually i need controling the view programmatically from the server side becose i will need to persist components properties in the database in order to make the website having the CMS property of retrieving the previous state of the view after a disconnection/connection. But anyway this is really an important and practical technic to master for several usages since the code to create the components exists..
Sorry for my bad english , i wish you understood what i tried to explain.
bouhmid Feki
Greenhorn

Joined: Apr 03, 2013
Posts: 6
Well, i made some steps ahead in order to resolve this issue and i asked another related question here http://stackoverflow.com/questions/15808956/how-to-programmatically-add-an-ajax-behavior-to-a-uicomponent-with-primefaces. I m still waiting for an answer..

Thanks for help !
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15952
    
  19

The reason I ask is that whenever I see people playing around with JSF internals, it's usually a sign that they don't know what they are doing. JSF is designed to do as much as possible using POJOs, so the presence of code that invokes any javax.faces classes other than the model classes sets off a fire alarm with me.
bouhmid Feki
Greenhorn

Joined: Apr 03, 2013
Posts: 6
If you say so but let's take the Jquery .append() as an example : JSF programmers can't get the benefits of this method (and others methods from the Jquery API) as JSF only consider components generated by its own life cycle. For example, a commandLink added with the .append() method won't work even it's created statically. And for this reason i'm trying to extend my abilities using code in POJOs (as you said that JSF is designed to do as much as possible using POJOs). I think that JSF framwork will loose its charm if it can't work together with Jquery or at least offer another alternative like manipulating components dynamically.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15952
    
  19

I have a lot of respect for jQuery. What little sanity I have left after dealing with JavaScript is mostly due to jQuery. But jQuery is not an appropriate mechanism to add/remove JSF View elements, since the View is generated by the server and jQuery operates on the client. AJAX is much better for that.


I have, in the years since I have been working with JSF (2006) only developed one application that dynamically modifies the JSF Component tree. It builds a data entry form based on interpreting general-purpose database schema definitions (It's a general-purpose database table editor). All of my other dynamic page layouts have been done by simpler means.

In most cases, you can dynamically add elements to a View by containing them in a dataTable or a ui:repeat construct. These components can replicate elements as needed, based on data in their respective Models. Dynamic partial-page updating can be done via AJAX, which will can the model to re-render the affected areas.

A JavaBean that's loaded with framework-specific code is not a POJO. POJO stands for Plain Old Java Object, and the ideal POJO works identically both within JSF and totally stand-alone (for example, in jUnit tests). In fact, a true POJO can be shared between multiple frameworks.

I do quite a bit of dynamic page work myself, so I'm not just speaking theoretically here. JSF really can accomplish a lot without requiring framework-specific coding, and that's by design, It's an Inversion of Control architecture where stock objects are wired together and controlled by JSF itself as opposed to more traditional systems where the program has to do all the work itself.

There are, of course, limits to what you can do in JSF without accessing the component tree, but they're not all that common. For one thing, once a page layout gets too dynamic, users get confused and you can't point to a picture in the documentation because what's on the screen won't look that much like the picture.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: A programmatically added AjaxBehaviour into a CommandLink doesn't work
 
Similar Threads
JButton question
use commandLink, get value eq null in backing bean
How to add programmatically RichFaces a4j:attachQueue
Inner Class
dynamic ajax behaviour