Re: Need some design ideas

[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

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