On 2/20/06, Leila Carvalho <[EMAIL PROTECTED]> wrote:
>
> Craig,
> First of all, congratulations for your Struts-Faces library!!
> This library is what I have been looking for..
>
> be careful of one particular scenario. Struts only creates one instance
> of
> > an Action class for the entire application, so that is not a good place
> to
> > put request-specific event handlers.
>
>
> --great!!!
> I´m newbie in Faces, so I´m dissecting struts-faces' very good examples 1
> and 2.
> I´m sure that all run well for actionEvents and there are some backing
> beans
> for that.
> Please, is there some sample code for Value-change Events in
> Struts-Faces???
> I would like saving time not doing my own tests...
>
> >By the way, are you writing a new application, or trying to adapt
> something
> that already exists?
>
> --My Struts application already exists. All I need at first is avoiding
> JavaScript when
> relating 2 modal comboboxes. Can I apply Value-change Events instead??
Here is an outline of one way to accomplish this task -- it's not by any
means the only possible pattern.
I need to start with an assumption -- that the relationship between the two
combo boxes is specific to a particular user? If so, that means the backing
bean we are talking about will naturally fit into session scope. Next, I'll
make one more assumption ... the set of options in the second checkbox
should depend on the user's choice in the first box. If I'm correct so far,
let's pretend the first combobox is the set of US states, and the second one
changes to be the set of cities appropriate to that state. This is just to
make the illustration clearer.
Now, assume you have a backing bean called "geography" that is defined to be
a managed bean in session scope. On this bean, you'll have two methods:
// Return selection items for *all* states
public SelectItem[] getStates() { return this.states; }
// Return selection items for cities in the specified state
public SelectItem[] getCities() { return this.cities; }
With a couple of instance variables (by the way, SelectItem is the
representation of the label and value of a particular option to show in a
dropdown).
// Initialize the states list to all the state abbreviations and names
private SelectItem[] states = new SelectItem[] {
new SelectItem("AL", "Alabama"),
new SelectItem("AK", "Alaska"),
...
}
// Initialize the cities list to a zero-length arary
private SelectItem[] cities = new SelectItem[0];
In addition, this bean might have a value change listener method like this:
// Respond to changes in which state is selected
public void stateChanged(ValueChangeEvent event) {
String newState = (String) event.getNewValue();
cities = ... calculate array of cities based on the value of
newState ...
}
Putting this together into one page, you would have your two combo boxes
declared something like this:
<h:selectOneMenu id="state" value="#{formBean.state}"
valueChangeListener="#{geography.stateChanged}">
<f:selectItems value="#{geography.states}"/>
</h:selectOneMenu>
<h:selectOneMenu id="city" value="#{formBean.city}">
<f:selectItems value="#{geography.cities}"/>
</h:selectOneMenu>
There are a couple of issues still to deal with your comment about doing
this kind of thing "without Javascript" but the details really depend on how
seriously that is actually to be taken. Making this work with Javascript
disabled in the browser, for example, is possible ... but you have to be
ready to deal with the fact that you need the entire form submitted for the
value change event to be fired, since it (like all the other events that JSF
defines) happen on the *server*, not on the *client*.
It's also possible to look for combo box components that are more
sophisticated than the one defined by the standard ... perhaps even one that
uses AJAX techniques to change the city list on the fly, without requiring a
form submit. But any component like this is going to depend on being able
to execute Javascript in the client.
Thanks!!
> ----------
>
>
Craig
