Ultimately I think you should probably read some of the existing books
on the subject. I am almost finished with Mastering Java Server Faces
(Wiley). Its excellent and cooincidentally, I just finished the
rather in depth chapter on events.
As an added bonus, one of the books authors (Bill Dudney) makes
appearances on the myfaces mailing lists.
One caveat to the book though is that there is some dated information
due to the spec changing at publishing time of the book. The
discrepancies are minor though (but there are a few specifically
related to events) and most books on new technologies have them.
I've tried to learn JSF by reading tutorials and online articles but
they don't really do it justice. Also, the specification is actually
quite informative. I would recommend reading that for a better
understanding as well.
sean
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?
>
> 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
> >
> >
> >
> >
> >
>
>
