On Mon, 17 Jan 2005 10:31:06 -0800, Michael McGrady <[EMAIL PROTECTED]> wrote:
> I have never actually understood events. Does someone have a good > tutorial or a good application (not the java GUI stuff) to learn from? At the innermost level, events and listeners are design patterns defined by the JavaBeans specification (http://java.sun.com/products/javabeans/docs/spec.html). This isn't tutorial level stuff, but the terminology described here is pretty much universal across Java APIs. The J2EE Tutorial (http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html) has several chapters on using JSF. The most important starting point is "The Lifecycle of a JavaServer Faces Page" in Chapter 17; later chapters also lightly discuss using event listeners. I'd also check out the resources at jsfcentral.com to get pointers to articles that have been written about JSF event handling. <commercial> Events are used in nearly every component related tutorial for Sun Java Studio Creator (http://developer.sun.com/prodtech/javatools/jscreator/learning/tutorials/index.jsp), but you have to be a customer to read them (rich content is part of what you pay for). Creator also makes it really easy to use events ... for example, double click on an input field and Creator will build you a value change method in the backing bean, create a method binding for you, and then position the cursor inside that method so you can write whatever event handling code you need. </commercial> > > Michael > Craig > 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 > > > > > > > > > > > >
