> * 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
