You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Sean Schofield <se...@gmail.com> on 2005/01/17 17:34:43 UTC
Need some design ideas
I'm going to be migrating an application to JSF during the course of
this year and I am starting to think about some of the particular
design issues. Any feedback would be appreciated.
The problem is that I need a list of changes from a form. The current
way I'm doing this is to clone the "document" object that is bound to
these values in my Struts form and then compare the two objects using
some of the commons BeanUtils stuff. This works pretty well and in
the end, I get a list of changes that I can pass through a "chain of
responsibility" pattern where each element of the chain can inspect
the list of changes for ones they are interested in.
I love the value change listener option in JSF and I think this will
be a big improvement for me. I don't have to implement clone methods
on my document bean (and the many properties that are also document
beans).
What I'm trying to avoid is adding a listener manually through the JSF
page to every element (since I'm basically interested in all changes
so I need them all.) I had an idea that I could have a request scope
bean that could be the listener for all changes. That bean would
compile the master list of changes as it received that value change
events from all of the components its listening to.
Then I could have a request-level bean that would listen for the end
of the "update model values" phase. That bean could take the list of
changes and call some business logic methods through a facade. Since
the model would be updated at this point, I could pass references to
those beans to the facade depending on the nature of the change (ex.
change in document owner).
What do you guys think about this general approach?
sean
Re: Need some design ideas
Posted by Craig McClanahan <cr...@gmail.com>.
On Mon, 17 Jan 2005 10:31:06 -0800, Michael McGrady
<mi...@michaelmcgrady.com> 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
> >
> >
> >
> >
> >
>
>
Re: Need some design ideas
Posted by Sean Schofield <se...@gmail.com>.
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
<mi...@michaelmcgrady.com> 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
> >
> >
> >
> >
> >
>
>
Re: Need some design ideas
Posted by Michael McGrady <mi...@michaelmcgrady.com>.
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:mike@michaelmcgrady.com]
>>Sent: Monday, January 17, 2005 7:31 PM
>>To: MyFaces Discussion
>>Cc: craigmcc@apache.org
>>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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
>
>
>
>
RE: Need some design ideas
Posted by Matthias Wessendorf <ma...@matthias-wessendorf.de>.
No!
index.html
and
index1.html
:-)
> -----Original Message-----
> From: Michael McGrady [mailto:mike@michaelmcgrady.com]
> Sent: Tuesday, January 18, 2005 9:03 AM
> To: MyFaces Discussion
> Subject: Re: Need some design ideas
>
>
> Thanks! You gave me two URLs that are the same, however.
>
> 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:mike@michaelmcgrady.com]
> >>Sent: Monday, January 17, 2005 7:31 PM
> >>To: MyFaces Discussion
> >>Cc: craigmcc@apache.org
> >>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
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >
> >
> >
> >
> >
> >
>
>
Re: Need some design ideas
Posted by Michael McGrady <mi...@michaelmcgrady.com>.
Thanks! You gave me two URLs that are the same, however.
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:mike@michaelmcgrady.com]
>>Sent: Monday, January 17, 2005 7:31 PM
>>To: MyFaces Discussion
>>Cc: craigmcc@apache.org
>>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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
>
>
>
>
RE: Need some design ideas
Posted by Matthias Wessendorf <ma...@matthias-wessendorf.de>.
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:mike@michaelmcgrady.com]
> Sent: Monday, January 17, 2005 7:31 PM
> To: MyFaces Discussion
> Cc: craigmcc@apache.org
> 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
> >
> >
> >
> >
> >
>
>
Re: Need some design ideas
Posted by Michael McGrady <mi...@michaelmcgrady.com>.
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
>
>
>
>
>
Re: Need some design ideas
Posted by Sean Schofield <se...@gmail.com>.
> * 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
Re: Need some design ideas
Posted by Craig McClanahan <cr...@gmail.com>.
On Mon, 17 Jan 2005 18:28:12 -0500, Sean Schofield
<se...@gmail.com> wrote:
> Wow! The more I read Craig's post the more clear things are starting to become.
>
> A couple of points about your response. You mentioned that you would
> dispatch your field changes to a chain to handle. I agree. That is
> the approach I'm going to use. Its just that there will be a lot of
> field changes. It might be nice to have to know all of them without
> registering each field specifically. I'm going to investigate the
> option of customizing my view component for this.
>
> Your description about how you organize your backing beans is *most*
> helpful. I've been struggling to figure out how to organize things.
> The JSF books all mention backing beans but I think they fall short
> describing a comprehensive strategy for using them. This is probably
> because the concept of a backing bean is so open-ended, but that
> precisely what I was having trouble with.
>
> I like your concept of having one backing bean per page. Also
> describing these in terms of their Struts counterparts is helpful.
>
> A question on how you use backing beans. Does it make sense to have
> some application scope beans that contain lookup data, etc. that
> doesn't ever change? I could see a situation there where you might
> have a few of your backing bean properties point to these types of
> beans. Perhaps also with a scheme for invalidating the data when it
> needs to be refreshed.
>
It does indeed make sense to have application scope backing beans.
They're useful for caching stuff that is common to all users (in the
Shale example app, I use an application scoped bean to cache localized
values for dropdown lists, for example). In a similar vein, you can
use session scoped backing beans to hang on to information that is
specific to a particular user, when you need it across more than one
request.
These two concepts are pretty much the same when you use JSF or any
other technology for dynamic content generation, but there is one
particular JSF-related goodie I also like -- you can let the managed
beans facility create these things for you the first time a value
binding expression refers to them, and not have to worry about
pre-initializing everything.
Craig
> Finally, it looks like organizing the backing beans as you suggest
> will allow me to take advantage of the new shale goodies you are
> working on. You definitely have my attention on that ... I will keep
> investigating your work.
>
> sean
>
>
> On Mon, 17 Jan 2005 09:27:42 -0800, Craig McClanahan <cr...@gmail.com> wrote:
> > A couple of thoughts on the details of what you're describing:
> >
> > * 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}"/>
> >
> > where myListener() is a public void method that accepts a
> > ValueChangeEvent. This isn't a lot more concise than nested
> > tags if you need them on every single input component, but is
> > pretty handy if you only need a few of them.
> >
> > * 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.
> >
> > As to general architectural style, I don't personally build
> > applicatons based on fine grained changes to individual fields ... I
> > find it easier to have my action handlers deal with all the values
> > (the same way that a Struts app would deal with all the form bean
> > fields), and dispatch to a processing chain (or whatever) there.
> > 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, along the
> > following lines:
> >
> > * Each JSP page has a corresponding backing bean
> > (Shale calls it a ViewController) that contains the
> > *values* of all the input fields (like a Struts form bean
> > but JSF takes care of conversions for you), plus
> > methods for all your submit buttons and event listeners.
> >
> > * The backing bean is a managed bean in request scope,
> > so it acts like a combination of a Struts form bean and an
> > action (without having to worry about thread safety, since
> > there is an instance per request)
> >
> > * The JSP page uses value binding expressions on each
> > input field to the corresponding property in the backing bean.
> >
> > * The JSP page uses method bindings on the "action"
> > attribute of submit buttons, binding them to an appropriate
> > action method in the same backing bean.
> >
> > * The action methods themselves would then gather up
> > whatever values they need (from the instance variables,
> > since you're in the same bean) and pass them to the
> > facade. Alternatively, if you're willing to tie your facade
> > to view tier APIs, you could pass the backing bean itself,
> > since it contains properties for all the relevant values.
> >
> > Fine grained value change processing, for *all* input fields, strikes
> > me as a lot more work ... but if it works for you, that's ok too.
> >
> > Craig
> >
> >
> > On Mon, 17 Jan 2005 11:34:43 -0500, Sean Schofield
> > <se...@gmail.com> wrote:
> > > I'm going to be migrating an application to JSF during the course of
> > > this year and I am starting to think about some of the particular
> > > design issues. Any feedback would be appreciated.
> > >
> > > The problem is that I need a list of changes from a form. The current
> > > way I'm doing this is to clone the "document" object that is bound to
> > > these values in my Struts form and then compare the two objects using
> > > some of the commons BeanUtils stuff. This works pretty well and in
> > > the end, I get a list of changes that I can pass through a "chain of
> > > responsibility" pattern where each element of the chain can inspect
> > > the list of changes for ones they are interested in.
> > >
> > > I love the value change listener option in JSF and I think this will
> > > be a big improvement for me. I don't have to implement clone methods
> > > on my document bean (and the many properties that are also document
> > > beans).
> > >
> > > What I'm trying to avoid is adding a listener manually through the JSF
> > > page to every element (since I'm basically interested in all changes
> > > so I need them all.) I had an idea that I could have a request scope
> > > bean that could be the listener for all changes. That bean would
> > > compile the master list of changes as it received that value change
> > > events from all of the components its listening to.
> > >
> > > Then I could have a request-level bean that would listen for the end
> > > of the "update model values" phase. That bean could take the list of
> > > changes and call some business logic methods through a facade. Since
> > > the model would be updated at this point, I could pass references to
> > > those beans to the facade depending on the nature of the change (ex.
> > > change in document owner).
> > >
> > > What do you guys think about this general approach?
> > >
> > > sean
> > >
> >
>
Re: Need some design ideas
Posted by Sean Schofield <se...@gmail.com>.
Wow! The more I read Craig's post the more clear things are starting to become.
A couple of points about your response. You mentioned that you would
dispatch your field changes to a chain to handle. I agree. That is
the approach I'm going to use. Its just that there will be a lot of
field changes. It might be nice to have to know all of them without
registering each field specifically. I'm going to investigate the
option of customizing my view component for this.
Your description about how you organize your backing beans is *most*
helpful. I've been struggling to figure out how to organize things.
The JSF books all mention backing beans but I think they fall short
describing a comprehensive strategy for using them. This is probably
because the concept of a backing bean is so open-ended, but that
precisely what I was having trouble with.
I like your concept of having one backing bean per page. Also
describing these in terms of their Struts counterparts is helpful.
A question on how you use backing beans. Does it make sense to have
some application scope beans that contain lookup data, etc. that
doesn't ever change? I could see a situation there where you might
have a few of your backing bean properties point to these types of
beans. Perhaps also with a scheme for invalidating the data when it
needs to be refreshed.
Finally, it looks like organizing the backing beans as you suggest
will allow me to take advantage of the new shale goodies you are
working on. You definitely have my attention on that ... I will keep
investigating your work.
sean
On Mon, 17 Jan 2005 09:27:42 -0800, Craig McClanahan <cr...@gmail.com> wrote:
> A couple of thoughts on the details of what you're describing:
>
> * 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}"/>
>
> where myListener() is a public void method that accepts a
> ValueChangeEvent. This isn't a lot more concise than nested
> tags if you need them on every single input component, but is
> pretty handy if you only need a few of them.
>
> * 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.
>
> As to general architectural style, I don't personally build
> applicatons based on fine grained changes to individual fields ... I
> find it easier to have my action handlers deal with all the values
> (the same way that a Struts app would deal with all the form bean
> fields), and dispatch to a processing chain (or whatever) there.
> 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, along the
> following lines:
>
> * Each JSP page has a corresponding backing bean
> (Shale calls it a ViewController) that contains the
> *values* of all the input fields (like a Struts form bean
> but JSF takes care of conversions for you), plus
> methods for all your submit buttons and event listeners.
>
> * The backing bean is a managed bean in request scope,
> so it acts like a combination of a Struts form bean and an
> action (without having to worry about thread safety, since
> there is an instance per request)
>
> * The JSP page uses value binding expressions on each
> input field to the corresponding property in the backing bean.
>
> * The JSP page uses method bindings on the "action"
> attribute of submit buttons, binding them to an appropriate
> action method in the same backing bean.
>
> * The action methods themselves would then gather up
> whatever values they need (from the instance variables,
> since you're in the same bean) and pass them to the
> facade. Alternatively, if you're willing to tie your facade
> to view tier APIs, you could pass the backing bean itself,
> since it contains properties for all the relevant values.
>
> Fine grained value change processing, for *all* input fields, strikes
> me as a lot more work ... but if it works for you, that's ok too.
>
> Craig
>
>
> On Mon, 17 Jan 2005 11:34:43 -0500, Sean Schofield
> <se...@gmail.com> wrote:
> > I'm going to be migrating an application to JSF during the course of
> > this year and I am starting to think about some of the particular
> > design issues. Any feedback would be appreciated.
> >
> > The problem is that I need a list of changes from a form. The current
> > way I'm doing this is to clone the "document" object that is bound to
> > these values in my Struts form and then compare the two objects using
> > some of the commons BeanUtils stuff. This works pretty well and in
> > the end, I get a list of changes that I can pass through a "chain of
> > responsibility" pattern where each element of the chain can inspect
> > the list of changes for ones they are interested in.
> >
> > I love the value change listener option in JSF and I think this will
> > be a big improvement for me. I don't have to implement clone methods
> > on my document bean (and the many properties that are also document
> > beans).
> >
> > What I'm trying to avoid is adding a listener manually through the JSF
> > page to every element (since I'm basically interested in all changes
> > so I need them all.) I had an idea that I could have a request scope
> > bean that could be the listener for all changes. That bean would
> > compile the master list of changes as it received that value change
> > events from all of the components its listening to.
> >
> > Then I could have a request-level bean that would listen for the end
> > of the "update model values" phase. That bean could take the list of
> > changes and call some business logic methods through a facade. Since
> > the model would be updated at this point, I could pass references to
> > those beans to the facade depending on the nature of the change (ex.
> > change in document owner).
> >
> > What do you guys think about this general approach?
> >
> > sean
> >
>
Re: Need some design ideas
Posted by Sean Schofield <se...@gmail.com>.
For the record I have found one more reason why I shouldn't decorate
the event. The data table component already wraps original events in
its queueEvent method. It does this so that when its time to
broadcast the event it knows which component in the data model that
event applies to.
The broadcast() method will check the event to see if its an
instanceof the private wrapper class. This check would fail if I were
to decorate the event with yet another private class.
I had given up on that approach a while ago (b/c I had suspected a
problem along these lines.) Now I have the concrete proof of how this
would fail.
sean
On Wed, 26 Jan 2005 07:49:22 -0600, Heath Borders
<he...@gmail.com> wrote:
> Well, since you are the one that writes the event listener, you can
> impose your own more stringent restrictions than that of the API, if
> necessary.
>
> On Tue, 25 Jan 2005 21:11:34 -0500, Sean Schofield
> <se...@gmail.com> wrote:
> > I've been thinking some more about this idea. I'm starting to think
> > that creating a new event will be problematic as well due to the
> > decorated nature of the source. Tampering with the source of the
> > event might have some undesirable side effects.
> >
> > One example would be that this would make it possible for event
> > handlers to remove the source of the event from the component tree.
> > I'm not quite sure why you'd want to do this, but you'd be ruling out
> > that possibility. Since the event listeners are expecting to hear
> > from the unaltered, original UIComponent that generating the event,
> > its probably not best to fool with it.
> >
> > sean
> >
> > On Fri, 21 Jan 2005 19:16:32 -0500, Sean Schofield
> > <se...@gmail.com> wrote:
> > > > I'm not quite sure in what context you are using the term "decorates".
> > > > JSF standard processing is going to walk up the parentage hierarchy,
> > > > *from* the component emitting the event *to* the UIViewRoot.
> > > > Therefore, unless you actually replace the component in question, in
> > > > the tree, this walking isn't going to see your decorating separate
> > > > component.
> > >
> > > Actually I was thinking about replacing the event itself (during queue
> > > event.) Basically creating a new one, with the decorated component as
> > > the source of the event.
> > >
> > > > See above ... you would have to replace the "real" component with your
> > > > decorating one, and that seems like a significant distortion to what
> > > > the user originally constructed.
> > >
> > > The original component tree remains intact. (see above)
> > >
> > > > Craig
> > >
> > > sean
> > >
> >
>
> --
> -Heath Borders-Wing
> hborders@mail.win.org
>
Re: Need some design ideas
Posted by Heath Borders <he...@gmail.com>.
Well, since you are the one that writes the event listener, you can
impose your own more stringent restrictions than that of the API, if
necessary.
On Tue, 25 Jan 2005 21:11:34 -0500, Sean Schofield
<se...@gmail.com> wrote:
> I've been thinking some more about this idea. I'm starting to think
> that creating a new event will be problematic as well due to the
> decorated nature of the source. Tampering with the source of the
> event might have some undesirable side effects.
>
> One example would be that this would make it possible for event
> handlers to remove the source of the event from the component tree.
> I'm not quite sure why you'd want to do this, but you'd be ruling out
> that possibility. Since the event listeners are expecting to hear
> from the unaltered, original UIComponent that generating the event,
> its probably not best to fool with it.
>
> sean
>
> On Fri, 21 Jan 2005 19:16:32 -0500, Sean Schofield
> <se...@gmail.com> wrote:
> > > I'm not quite sure in what context you are using the term "decorates".
> > > JSF standard processing is going to walk up the parentage hierarchy,
> > > *from* the component emitting the event *to* the UIViewRoot.
> > > Therefore, unless you actually replace the component in question, in
> > > the tree, this walking isn't going to see your decorating separate
> > > component.
> >
> > Actually I was thinking about replacing the event itself (during queue
> > event.) Basically creating a new one, with the decorated component as
> > the source of the event.
> >
> > > See above ... you would have to replace the "real" component with your
> > > decorating one, and that seems like a significant distortion to what
> > > the user originally constructed.
> >
> > The original component tree remains intact. (see above)
> >
> > > Craig
> >
> > sean
> >
>
--
-Heath Borders-Wing
hborders@mail.win.org
Re: Need some design ideas
Posted by Sean Schofield <se...@gmail.com>.
I've been thinking some more about this idea. I'm starting to think
that creating a new event will be problematic as well due to the
decorated nature of the source. Tampering with the source of the
event might have some undesirable side effects.
One example would be that this would make it possible for event
handlers to remove the source of the event from the component tree.
I'm not quite sure why you'd want to do this, but you'd be ruling out
that possibility. Since the event listeners are expecting to hear
from the unaltered, original UIComponent that generating the event,
its probably not best to fool with it.
sean
On Fri, 21 Jan 2005 19:16:32 -0500, Sean Schofield
<se...@gmail.com> wrote:
> > I'm not quite sure in what context you are using the term "decorates".
> > JSF standard processing is going to walk up the parentage hierarchy,
> > *from* the component emitting the event *to* the UIViewRoot.
> > Therefore, unless you actually replace the component in question, in
> > the tree, this walking isn't going to see your decorating separate
> > component.
>
> Actually I was thinking about replacing the event itself (during queue
> event.) Basically creating a new one, with the decorated component as
> the source of the event.
>
> > See above ... you would have to replace the "real" component with your
> > decorating one, and that seems like a significant distortion to what
> > the user originally constructed.
>
> The original component tree remains intact. (see above)
>
> > Craig
>
> sean
>
Re: Need some design ideas
Posted by Sean Schofield <se...@gmail.com>.
> I'm not quite sure in what context you are using the term "decorates".
> JSF standard processing is going to walk up the parentage hierarchy,
> *from* the component emitting the event *to* the UIViewRoot.
> Therefore, unless you actually replace the component in question, in
> the tree, this walking isn't going to see your decorating separate
> component.
Actually I was thinking about replacing the event itself (during queue
event.) Basically creating a new one, with the decorated component as
the source of the event.
> See above ... you would have to replace the "real" component with your
> decorating one, and that seems like a significant distortion to what
> the user originally constructed.
The original component tree remains intact. (see above)
> Craig
sean
Re: Need some design ideas
Posted by Craig McClanahan <cr...@gmail.com>.
On Fri, 21 Jan 2005 17:30:07 -0500, Sean Schofield
<se...@gmail.com> wrote:
> > * 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.
>
> What if I had a custom form component along with a class that
> decorates UIComponent? In my form component I could get override
> queueEvent and wrap the source of the event with my decorating class.
I'm not quite sure in what context you are using the term "decorates".
JSF standard processing is going to walk up the parentage hierarchy,
*from* the component emitting the event *to* the UIViewRoot.
Therefore, unless you actually replace the component in question, in
the tree, this walking isn't going to see your decorating separate
component.
>
> The decorating class would just delegate to the decorated instance for
> everything but the broadcast method. The broadcast method would
> notify the form's value change listener first and then call the
> "super" method.
>
> What do you think of that approach? Is there a problem wrapping the
> components in the tree (as long as the decorator extends UIComponent)?
See above ... you would have to replace the "real" component with your
decorating one, and that seems like a significant distortion to what
the user originally constructed.
>
> Thanks,
>
> sean
>
> > Craig
>
Craig
Re: Need some design ideas
Posted by Sean Schofield <se...@gmail.com>.
> * 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.
What if I had a custom form component along with a class that
decorates UIComponent? In my form component I could get override
queueEvent and wrap the source of the event with my decorating class.
The decorating class would just delegate to the decorated instance for
everything but the broadcast method. The broadcast method would
notify the form's value change listener first and then call the
"super" method.
What do you think of that approach? Is there a problem wrapping the
components in the tree (as long as the decorator extends UIComponent)?
Thanks,
sean
> Craig
Re: Need some design ideas
Posted by Craig McClanahan <cr...@gmail.com>.
A couple of thoughts on the details of what you're describing:
* 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}"/>
where myListener() is a public void method that accepts a
ValueChangeEvent. This isn't a lot more concise than nested
tags if you need them on every single input component, but is
pretty handy if you only need a few of them.
* 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.
As to general architectural style, I don't personally build
applicatons based on fine grained changes to individual fields ... I
find it easier to have my action handlers deal with all the values
(the same way that a Struts app would deal with all the form bean
fields), and dispatch to a processing chain (or whatever) there.
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, along the
following lines:
* Each JSP page has a corresponding backing bean
(Shale calls it a ViewController) that contains the
*values* of all the input fields (like a Struts form bean
but JSF takes care of conversions for you), plus
methods for all your submit buttons and event listeners.
* The backing bean is a managed bean in request scope,
so it acts like a combination of a Struts form bean and an
action (without having to worry about thread safety, since
there is an instance per request)
* The JSP page uses value binding expressions on each
input field to the corresponding property in the backing bean.
* The JSP page uses method bindings on the "action"
attribute of submit buttons, binding them to an appropriate
action method in the same backing bean.
* The action methods themselves would then gather up
whatever values they need (from the instance variables,
since you're in the same bean) and pass them to the
facade. Alternatively, if you're willing to tie your facade
to view tier APIs, you could pass the backing bean itself,
since it contains properties for all the relevant values.
Fine grained value change processing, for *all* input fields, strikes
me as a lot more work ... but if it works for you, that's ok too.
Craig
On Mon, 17 Jan 2005 11:34:43 -0500, Sean Schofield
<se...@gmail.com> wrote:
> I'm going to be migrating an application to JSF during the course of
> this year and I am starting to think about some of the particular
> design issues. Any feedback would be appreciated.
>
> The problem is that I need a list of changes from a form. The current
> way I'm doing this is to clone the "document" object that is bound to
> these values in my Struts form and then compare the two objects using
> some of the commons BeanUtils stuff. This works pretty well and in
> the end, I get a list of changes that I can pass through a "chain of
> responsibility" pattern where each element of the chain can inspect
> the list of changes for ones they are interested in.
>
> I love the value change listener option in JSF and I think this will
> be a big improvement for me. I don't have to implement clone methods
> on my document bean (and the many properties that are also document
> beans).
>
> What I'm trying to avoid is adding a listener manually through the JSF
> page to every element (since I'm basically interested in all changes
> so I need them all.) I had an idea that I could have a request scope
> bean that could be the listener for all changes. That bean would
> compile the master list of changes as it received that value change
> events from all of the components its listening to.
>
> Then I could have a request-level bean that would listen for the end
> of the "update model values" phase. That bean could take the list of
> changes and call some business logic methods through a facade. Since
> the model would be updated at this point, I could pass references to
> those beans to the facade depending on the nature of the change (ex.
> change in document owner).
>
> What do you guys think about this general approach?
>
> sean
>