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
