struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Jacobs <>
Subject Re: changing ActionForm to be a Java interface
Date Wed, 15 Jan 2003 12:51:39 GMT
Hi Craig,

I think your point below about form-beans being part of the framework is 
the "nub of the crux" of the problem.  There's not enough there for 
novice users to distinguish their responsibilities from those of 
"normal" Java Beans.

Customarily, object-oriented frameworks are extended solely in terms of 
behavior (it's that roles and responsibilities thing again).  In the 
case of form-beans, though, the Struts framework is defining a whole new 
kind of object.  The provided superclass has well defined capabilities, 
but only vaguely defined responsibilities.

If ActionForm was defined as an interface that specified methods for 
getting and setting fields with String names and String values, its 
responsibilities would be clearer.  Consequently it would be possible 
both for novice users to use the default implementations more reliably, 
and for competent engineers to provide alternative implementations.

In effect, by piggy-backing on beans-properties introspection for the 
sake of convenience, your novice users are lured into thinking that 
form-beans are beans, but they're really intended to be much more 
restricted in scope.

So, if you were to introduce an interface (say, IActionForm) that more 
clearly stipulated the intended roles and behavior, and documented the 
heck out of the default implementation to advise novices not to use the 
rest of beans capabilities indiscriminately, you might end up with a 
better framework for all classes of users.

And, of course, that would also make it easier for me to integrate 
JPlates more fully with Struts.  As to your question about whether 
JPlates objects could still be used for more than a single request, the 
answer is definitely yes.  JPlates objects can be kept directly in the 
session scope, or they can be referenced by form-beans, etc.  I'm 
currently employing both of those approaches, and I'd still like a more 
straightforward abstraction for form-objects that didn't require an 
awkward (and arguably unnecessary) delegation.

This is addressed (somewhat briefly) in my presentation about 
design-pattens in template-based apps.  There's a link to it at, in the documentation page.

-- Dan

Craig R. McClanahan wrote:


>>>>In particular, I want to be able to use JPlates objects (see
>>>> ) as ActionForms, since that would allow me to
>>>>encapsulate the full behavior of a form in the object, instead of just
>>>>having a place to put the data.  I can already use JPlates in place of
>>>>JSPs for rendering (which is wonderful!), but I'd have a more consistent
>>>>solution if I could use JPlates objects for my ActionForms as well.

>>Well, like I said, I use JPlates easily in place of JSPs for rendering,
>>because JPlates comes with a dispatching servlet similar to yours,
>>allowing JPlates to be addressed using URLs just like JSPs.   So in that
>>way, JPlates works with Struts just as well as Velocity.
>That was the design goal.  What people resist, though, is the notion that
>form beans belong to the framework, not to the view technology :-).
>>For ActionForms, though, I can only use JPlates instances by delegation
>>from an anstance of an ActionForm subclass, which is ok, but not idea.
>> I'd rather be able to implement IActionForm from a JPlates class and
>>delegate to an ActionForm if necessary.
>If you intermix the presentation capabilities of a JPlates object and the
>data storage capabilities of an ActionForm, doesn't that mean you would
>have to give up the (currently supported) capability to use the same form
>bean for more than one view page?
>To unsubscribe, e-mail:   <>
>For additional commands, e-mail: <>

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message