jQuery in Action, 3rd edition
The moose likes JSF and the fly likes default button / sequence of setter calls Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Java Interview Guide this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Java » JSF
Bookmark "default button / sequence of setter calls" Watch "default button / sequence of setter calls" New topic

default button / sequence of setter calls

Michael Moeller

Joined: Jan 25, 2007
Posts: 5

currently I'm working on a page that includes a form with a couple of simple inputText fields. The backing bean has a property for each text field with getter/setter methods. The content of one these text fields should be splitted and automatically written to the other fields when pressing enter. At least this is the plan;-)

1. When pressing "Enter" the page should not be turned over, but this is exactly what happens since the form has a "Next" button which seems to be the default button. Which is the best way to change this behavior? Is it possible to create another "default" button in the form, which just run the setters in the backing bean and then reload the page? And where do I have to place it (in the form)?

2. The setter method for the text field whose content should be splitted contains some logic for creating new texts for the other fields. At the end of this method the setters for the other fields are called explicitely with the new values in order to update a model in the business layer. As expected these setters are called again by JSF - but unfortunately after my programmatic calls, so the new values in the business model are overwritten. Is it possible to change the order of JSF backing bean setter calls?

Can anyone help me with these 2 issues?

Many thanks in advance...
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 17423

I don't think that there's any guarantee in the JSF spec as to what order setters or getters get invoked as far as which field gets touched first, second, third, and so forth, and since the backing bean is a JavaBean, such an assumption is not a good idea anyway.

You can get around this by using some of the JSF lifecycle modification options and/or event handlers.

Normally, I gather up all the changes and apply them in the action processor. At that point in the cycle, all the value changes are guaranteed to have been applied (assuming normal cycle), so I can enforce my own rules on things.

In some cases, I want more immediate displays, in which case I add JavaScript on the client page, but I try to remember that the user can switch off JavaScript, so I don't make proper functioning of the app depend on it.

As far as a "default" button goes, the rules are exactly the same as they would be if you were creating straight HTML - since that's what the JSF will ultimately be converted to.

An IDE is no substitute for an Intelligent Developer.
I agree. Here's the link: http://aspose.com/file-tools
subject: default button / sequence of setter calls
It's not a secret anymore!