struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colin Sampaleanu <co...@Bspark.com>
Subject RE: Auto-population of non ActionForm beans?
Date Thu, 21 Sep 2000 19:31:45 GMT
> -----Original Message-----
> From: Craig R. McClanahan [mailto:Craig.McClanahan@eng.sun.com]
> Sent: September 21, 2000 3:06 PM
> To: struts-user@jakarta.apache.org
> Subject: Re: Auto-population of non ActionForm beans?
> 
> "Duffey, Kevin" wrote:
> 
> > > That's the plan.
> >
> > Good.
> >
> > >
> > > Along the way we also need to deal with any syntax issues 
> related to
> > > JavaScript, as a couple of folks have pointed out.
> >
> > Uh...what issues with JavaScript exist? I haven't been 
> reading every mail,
> > so if you could point those out so that I am aware of it, 
> that would be much
> > appreciated. I am using JavaScript extensively with calling 
> actions, passing
> > parameters, etc. I want to make sure there isn't something 
> I am not aware
> > of.
> >
> 
> I described what my concerns were ("." is a significant character in
> JavaScript), and others have pointed out that you can work 
> around it in
> JavaScript with no problems.  So it might be a moot point.
> 
> >
> > > Inside Struts, anything and everything to do with
> > > auto-population will use the
> > > same underlying PropertyUtils and BeanUtils code, so fixing
> > > it once fixes it
> > > for all.
> >
> > Good. Right now, I am sort of "bypassing" the struts 
> auto-population so that
> > I can use our nested population code. I would rather use the Struts
> > framework for this, but until its provided I am stuck using 
> our own brew. I
> > look forward to the autopopulation of Struts allowing non-ActionForm
> > implemented classes for population..that is the plan right?
> 
> As soon as I commit the next set of changes to BeanUtils, the
> BeanUtils.populate() method will support the new syntax.
> 
> As for the auto-population that the Struts controller servlet 
> does, the
> consensus was to keep ActionForm.  This is actually a good 
> decision, for the
> reasons discussed further below.  You really should NOT be 
> using the same class
> to hold the form values and your real database data (whether 
> it is an EJB or
> not).  Requiring you to implement ActionBean pushes you in the correct
> application architecture direction :-).
> 
> > > By the way, this is one of the reasons *not* to try reusing
> > > entity objects in
> > > your data model as form beans.  Those should always be
> > > separate, because form
> > > beans only have the purpose of maintaining state for the
> > > presentation layer.
> >
> > Actually, I don't know if I made it clear enough before. We 
> are not using
> > entity (as in EJB entity) objects. We are repackaging our 
> code into a
> > "framework" for the whole media industry to use. Basically, 
> the "core" code
> > in our structure represents a number of entities in the 
> media business. As
> > we acquire companies, or work with others, we can modify 
> the entity as
> > needed, but in general, our framework is based on these 
> core foundation
> > classes, as should be the case for those we work with or acquire.
> >
> > I think the main purpose of doing the nested population of 
> generic beans
> > instead of those that derive from ActionForm is so that our 
> "core" classes
> > don't have to implement (or extend..as I just read its now 
> a class and not
> > an interface) ActionForm.
> 
> By the way, ActionForm is still an interface.  It is 
> ActionMapping that was
> changed.  IMHO ActionForm will always need to be an 
> interface, because people
> really will reuse existing classes (with their own base 
> classes) when they feel
> it is appropriate.
> 
> > We can't have our core industry used beans rely on
> > ActionForm, but we also don't want to have to type in the 
> many hundreds of
> > getter/setter methods for javabeans used on pages since 
> they are the same
> > methods already defined in our core classes. What do you 
> think of this
> > approach?
> 
> As we have discussed before, and as I described recently 
> (yesterday?) when
> discussing this, I don't think this is the best approach.
> 
> For displaying things, I don't see a huge problem with using 
> nested and indexed
> property getters to access existing entity beans (although 
> the syntax of the
> nested getter name *does* create a dependency between your 
> presentation and the
> way that your entity data beans are related to each other).
> 
> For form beans that are auto-populated by the Struts 
> framework, however, I
> recommend that you do *not* use your entity data beans 
> directly.  The reasons
> were explained more thoroughly yesterday, but there are 
> basically two issues:
> 
> * Entity data beans (whether EJBs or not does not matter) usually have
>   validation checks that won't accept invalid data (i.e. a 
> null value for
>   customer name when the bean says it's required).
> 
> * If your transaction is multi-page and you are modifying the real
>   entity data beans, how do you deal with it when the user decides
>   to leave without completing the transaction?
> 
> To deal with the "extra work" of creating form beans that 
> have pretty much the
> same set of fields, two things are needed:
> 
> * Development tools to auto-create form bean classes.  Several
>   proposals have been presented on how to do this, and some
>   finished tools have been presented.
> 
> * An easy way to copy property values with matching names from
>   the form bean to the entity data bean when the transaction is really
>   completed and validated.  For this, see the method
>   PropertyUtils.copyProperties(Object dest, Object orig).
> 
> 
> > I personally would rather use javabeans, but our main engineer
> > here has felt its a waste of our time to duplicate the getter/setter
> > methods, that is why he wrote that code and we are now 
> using it. I can see
> > his point..it makes no sense to have the same method call 
> basically pass on
> > the value from a form to another class that calls upon the 
> same method..its
> > nicer to "pass through" to the actual method of the entity, 
> since they have
> > the same names. Can you give a good reason this shouldn't be done?
> >
> 
> The point is that you *don't* just "pass it on" immediately.  
> You accumulate the
> changes in the form beans until you are ready to accept the 
> entire transaction,
> then you apply them all at once.  Besides dealing with the 
> two issues described
> above, this technique is also useful in minimizing the amount 
> of time database
> rows are locked when you are actually doing the update 
> (often, applications lock
> the underlying database row when they start updating the 
> entity data bean
> representation of the underlying data).
> 
> Different applications have different design requirements 
> that sometimes lead to
> different design choices.  That's fine, but Struts is going 
> to encourage a
> particular model of separated form beans (presentation layer) 
> and entity data
> beans (persistence layer).
> 
> Of course, since it's open source, you can subclass and 
> modify that behavior if
> you want to :-).  Quite a few folks seem to have their own 
> customized version of
> Struts, changed in ways that meet their own requirements.

What is the actual problem with the bean populator dealing in terms of
Object instances, which it assumes are JavaBeans, and doing extra checks to
see if the instance supports ActionForm or ValidatingActionForm, and adding
special behaviour based on that as needed (although ActionForm doesn't do
anything at the moment, of course). I would agree that if you have an EJB
data object which does its own validation, etc., it's probably not the best
idea to use it as a form bean. On the other hand, people are also going to
be using struts in smaller projects where there are existing simple
JavaBeans being passed around, and creating a new bean class would be total
duplication of existing code.

Mime
View raw message