Sorry, I missed the difference. Thanks again.
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
