struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: changing ActionForm to be a Java interface
Date Wed, 15 Jan 2003 03:22:01 GMT

On Tue, 14 Jan 2003, Dan Jacobs wrote:

> Date: Tue, 14 Jan 2003 20:36:19 -0500
> From: Dan Jacobs <>
> Reply-To: Struts Users Mailing List <>
> To:
> Subject: changing ActionForm to be a Java interface
>   Hi all,
> I know this is very late in the 1.1 game to change things very much, but
> I'd like to make an API change request.
> Currently, ActionForm is defined as a class rather than as an interface.
>  The problem with that is that it doesn't allow other kinds of objects
> to act as ActionForms.

It's not going to happen -- absolutely positively not for 1.1, and
(pretty much) over my dead body for any subsequent 1.x release.  I'm
taking advantage of the single inheritance restriction of Java to make it
more difficult for most people to do things that they should not do.

A bit of history -- up to Struts 0.5, ActionForm was indeed an interface.
The problem is that *way* too many people tried to use the ActionForm as a
value object, which was wrong for two reasons:

* It encouraged you to make the property types match
  the underlying business tier instead of Strings,
  which violated one of the primary
  purposes for ActionForms in the first place (the ability
  to reproduce invalid input, which is a fundamental
  user expectation).

* It tied your business tier to Struts APIs, which meant
  you had to import things like servlet.jar into places
  that it has no business at all.

Because it was obvious that people were going to misuse the Struts APIs in
this way, I switched ActionForm to being a class instead.  People still
try to misuse it :-), but most of them find it easier to do what they
really should do in the first place -- use plain old JavaBeans (POJOs) for
value objects.

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

Can you use the "nested" facilities to make this integration happen one
layer deeper?  In other words, you can define an ActionForm (or
DynaActionForm) with a single nested property that points at your JPlates
objects, or otherwise wraps them?

I also find it interesting that the JPlates docs think that their
technology will work just fine with Struts, without making this kind of a
change ...

> For the sake of compatibility with existing Struts applications, what I
> propose is:
>    1. interface IActionForm (yeah, I don't like that convention much
>       either) would define the interface methods.
>    2. class ActionForm implements IActionForm would be used pretty much
>       the way it's used now.
>    3. the internals of Struts would be changed to use IActionForm
>       wherever ActionForm is currently used.
>    4. other kinds of objects could implement IActionForm directly or by
>       delegation to an ActionForm.
> I'd be happy to help out to make this change.
> Dan Jacobs
> President, ModelObjects Group
> Chairman, Boston ACM WebTech Group

Craig McClanahan

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message