No!
index.html and index1.html :-) > -----Original Message----- > From: Michael McGrady [mailto:[EMAIL PROTECTED] > Sent: Tuesday, January 18, 2005 9:03 AM > To: MyFaces Discussion > Subject: Re: Need some design ideas > > > Thanks! You gave me two URLs that are the same, however. > > Michael > > Matthias Wessendorf wrote: > > >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 > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >> > >> > > > > > > > > > > > > > >
