dev@javaserverfaces.java.net

Re: ValueChangeEvent phases

From: Mark Collette <mark.collette_at_icesoft.com>
Date: Tue, 20 May 2008 12:31:35 -0600

Sorry to be cheesy and use such a blatantly advertising example, but
this is the easiest way to show you an example, with the source code:

http://component-showcase.icefaces.org/component-showcase

1. In the tree to the left, click on "Extended Components", and then
"Selection"
2. Select a country from the list, and then select some cities
3. Select a different country
4. Notice that the city list was cleared. This is because of additional
code in the bean to work around the issue that when you click on the new
country, in the country valueChangeListener we set the list of selected
cities to an empty list, but the old cities still propagate through the
lifecycle, and get set into the bean after the the valueChangeListener.
5. Click on the "Source" tab, and then "
<http://component-showcase.icefaces.org/component-showcase/showcase.iface#>SelectionTagsBean.java"
6. Read the source for: public void countryChanged(ValueChangeEvent
event) and public String getSelectedCitiesStrings()
7. You'll see that whoever wrote that code chose to use some
hand-shaking via a boolean countryChanged field. They could have also
used the ValueChangeEvent requeuing technique. This was necessary,
because in getSelectedCitiesStrings(), selectedCities is actually set to
the list of previously selected cities, even though we set it to an
empty String[] in countryChanged.


This example might not be the best, since the city lists were explicitly
coded to be different between countries, but it's fairly common in real
life to have similar city names between countries and even provinces or
states. In that case, a lingering city selection would misinform users.
And I'm sure you can imagine other examples, where users populate an
inputText from a drop down list, but the old text remains, after
clicking on an entry in the list.

It would be easier to code if there was some way of specifying that the
valueChangeEvent should happen after UpdateModelPhase.


Mark Collette
ICEsoft Technologies, Inc.
http://mark-icefaces-reflections.blogspot.com/


Kito D. Mann wrote:

>Mark,
>
>Can you provide a more concrete example of the problem?
>
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>Kito D. Mann - Author, JavaServer Faces in Action
>http://www.virtua.com - JSF/Java EE consulting, training, and mentoring
>http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
>phone: +1 203-653-2989
>fax: +1 203-653-2988
>
>
>
>
>>-----Original Message-----
>>From: Mark Collette [mailto:mark.collette_at_icesoft.com]
>>Sent: Friday, May 16, 2008 5:38 PM
>>To: dev_at_javaserverfaces.dev.java.net
>>Subject: ValueChangeEvent phases
>>
>>Right now, you can use the immediate attribute on
>>UIInput/EditableValueHolder to determine if the ValueChangeEvent will
>>be
>>broadcast in ApplyRequestValuesPhase or ProcessValidationsPhase. But,
>>a
>>lot of the time, if one is using that to control the value of some
>>other
>>UIInput component, one would re-queue the event to be broadcast after
>>UpdateModelPhase or InvokeApplicationPhase, so that this other
>>UIInput's
>>value, being updated in UpdateModelPhase, won't stomp over the
>>programmatically set value from the ValueChangeListener.
>>
>>Is there anything in the JSF 2.0 specification for an attribute to make
>>it use UpdateModelPhase or InvokeApplicationPhase, so that developers
>>won't have to write the bean re-queuing code? Something that would
>>simplify things, and keep it more declarative.
>>
>>Mark Collette
>>ICEsoft Technologies, Inc.
>>http://mark-icefaces-reflections.blogspot.com/
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
>>For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
>For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
>
>
>