Michael, Hans Bergesten has two online articles regarding JSF and events:
http://www.onjava.com/pub/a/onjava/excerpt/JSF_chap8/index.html and http://www.onjava.com/pub/a/onjava/excerpt/JSF_chap8/index1.html HTH, Matthias > -----Original Message----- > From: Michael McGrady [mailto:[EMAIL PROTECTED] > Sent: Monday, January 17, 2005 7:31 PM > To: MyFaces Discussion > Cc: [EMAIL PROTECTED] > Subject: Re: Need some design ideas > > > I have never actually understood events. Does someone have a good > tutorial or a good application (not the java GUI stuff) to learn from? > > Michael > > Sean Schofield wrote: > > >>* A value change listener does not have to be a separate > class that > >>is registered by a nested tag in the page -- for the standard > >>components, at least, you can use a method binding: > >> > >> <h:inputText ... valueChangeListener="#{mybean.myListener}"/> > >> > >> > > > >True. But this would still be tedious to add this attribute > to all of > >the input tags. > > > > > > > >>* To transparently listen to *all* the events, one can gain an > >>inspiration from understanding how event firing is actually > done. A > >>component that wants to fire an event will call (on itself) the > >>queueEvent(FacesEvent) method. The default implementation of this > >>calls queueEvent() on the parent component, and so on up to the > >>UIViewRoot at the root of the tree, which does the actual > >>broadcasting later. If you had a parent custom component > around the > >>form, or a custom form component itself, it could "notice" all the > >>value change events that were being emitted and do something > >>interesting with them. > >> > >> > > > >Yes .... this was along the lines of what I was thinking. > > > > > > > >>As to general architectural style, I don't personally build > >>applicatons based on fine grained changes to individual fields ... > >> > >> > > > >I can see why you would think this tedious but my situation may be a > >bit unique. We have lots of fields on the form and each field > >potentially requires some special processing (not just saving the > >field.) We have a workflow engine connected to this > application that > >performs various operations on the workflow depending on which field > >changes. Also, we log all of the changes to the underlying > "document" > >in the application. So if someone changed the document > owner from x to > >y we'd want to log that. > > > >Would this change your opinion of my approach or do you > still think the > >approach you outlined would be better? > > > > > > > >>Indeed, the Shale Use Cases example app (nightly builds at > >><http://svn.apache.org/builds/struts/nightly/struts-shale/>) > >>illustrates my thoughts on how you do stuff like this > >> > >> > > > >OK. OK. I give up. Its time for me to look at your Shale > stuff in more > >detail ;-) > > > >I had been waiting until I had a sufficient level of > understanding of > >JSF before diving into Shale so as to not overwhelm myself. But the > >scenario you just outlined is too tempting to not look > further! Even > >though I'm not sure its right for me for this particular > problem, I'm > >interested in some of the ways in which you manage your > backing beans, > >etc. > > > >Thanks for the good ideas (as usual). > > > > > > > >>Craig > >> > >> > > > >sean > > > > > > > > > > > >
