Win a copy of Design for the Mind this week in the Design forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

default button / sequence of setter calls

 
Michael Moeller
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

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
Pie
Posts: 18094
48
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic