File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes JSF and the fly likes Circumventing the jsf Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Java » JSF
Bookmark "Circumventing the jsf "set" operation" Watch "Circumventing the jsf "set" operation" New topic
Author

Circumventing the jsf "set" operation

Lance Cash
Greenhorn

Joined: Oct 19, 2009
Posts: 17
Ok...here's the deal. I have a combo box on a page tied to a ValueChangeListener. When the combo box is changed, the value change method modifies the value backed by an input on the same page. However, after this value is changed in the code, whatever phase is responsible for setting that value from the UI is fired and passes the "UI value" and writes it over what I just changed it to. Is there some way to prevent this phase from executing when you must? Thanks in advance for any help you can provide. Thanks. Lance.
Lance Cash
Greenhorn

Joined: Oct 19, 2009
Posts: 17
Well, no takers on this one, huh? I am able to work around the issue by setting a flag in the value change method that the set method then looks at and skips setting the value if the flag is set and then resets the flag. But...that's really lame! There has to be a better way? Thanks. Lance.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16019
    
  20

You shouldn't set values in the ValueChangeListener. It's intended to LISTEN, not to act, and as you can see, modifying the data there can have unfortunate consequences.

I use ValueChangeListener for things like AJAX setup of dependent menus, but I still have a "set" method to actually change the data.


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

Joined: Oct 19, 2009
Posts: 17
I've got nothing but respect for you, Tim, but...that has to be one of the most ridiculous things I've ever heard. Don't use a VCL to change a value? I must be missing something huge here. How exactly are you supposed to accomplish simple tasks like I'm describing, then. A user changes a combo box selection and it subsequently changes a value in some other field on the page? I don't mean to sound rude, Tim, I'm just perplexed. Thanks. Lance.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16019
    
  20

I can understand that. The key to this riddle is that the value that gets changed is part of the view/controller mechanism, not part of the model. Although JSF is a much purer implementation of MVC than any of its predecessors, there's still only an imperfect fit.

The JSF lifecycle is predicated on propagating the illusion that the entire model is updated as a unit. You lose that illusion if some items get updated in the listeners and some get updated in the setters. This is especially true when you consider that in JSF, methods get called more than once as the lifecycle progresses.
Lance Cash
Greenhorn

Joined: Oct 19, 2009
Posts: 17
Ok, so what's the answer to the problem at hand?

How exactly are you supposed to accomplish simple tasks like I'm describing, then. A user changes a combo box selection and it subsequently changes a value in some other field on the page?


Thanks. Lance.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16019
    
  20

Well, if I've got cascading droplists, I have the listener reset the menu for the dependent droplist, and, since the menu probably doesn't have the previous secondary value set, I usually invalidate that. To make it easier to debug, I typically call its setter internally.

I'm generally doing that with RichFaces, so I make the dependent control part of the reRender set from an immediate action on the controlling droplist.

Um. Now that I think of it, I'm no longer sure I'm using a ChangeListener for that kind of stuff. I think I'm using an ajax4jsf "onchange" action. Let me go check.

Actually, I do both:


If I can read my own code properly (was was I high on when I wrote this?), the AJAX is intended to ensure that the actual controls fire off. I'm not sure if that's necessary or not. I spent some time fighting various quirks in the process and there maybe left-over redundant junk here.

Anyway, here's a typical listener:


cityList is the menu, and the getCityList method will load a new menu and save it if the current menu is null. Since the cityId associated with that menu is no longer valid, I nuke it.
Lance Cash
Greenhorn

Joined: Oct 19, 2009
Posts: 17
Ok, so see...you are setting the cityId value in your stateValueChanged() method.
Tim Holloway wrote:



This is what I'm doing in my code. My question is this: If there was already a value in the cityId field and then someone goes and changes the state, then your setting of the cityId to "" will be overwritten by the phase that sets the values from the jsf page, right? If not, what is preventing that from happening? Is that maybe where some of this a4j stuff comes in? Other than that, my code looks very similar to yours. Thanks for your help, Tim. Lance.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16019
    
  20

I've got to admit that it takes a little bit of puzzling out. And doing partial page updates just makes it that much more confusing.

It's a good idea to keep one eye on the JSF lifecycle diagrams when doing this kind of stuff. Unfortunately, I believe the most commonly-provided ones don't really indicate where the listeners get called (although as a rule, they precede their corresponding "do-er"s).

By doing a partial page submit, the State control runs through the lifecycle - including the validate and update steps, but the City control and its value does not. However, the ajax4jsf extension causes the City control to participate in the Display Update step, so when the state control zaps the city ID, the updated city ID doesn't get overlaid, but it does get referenced for the generated of the outgoing refresh of the City control.
 
wood burning stoves
 
subject: Circumventing the jsf "set" operation