struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: [Proposal] ActionFactory refactoring
Date Sat, 03 Jan 2004 00:30:59 GMT
Quoting Don Brown <>:

> What if we extracted the creation of Actions and ActionForms (including
> DynaActionForms) into an ActionFactory, overridable by the user?

The idea of factories for all Struts objects is an appealing one (I don't buy
the "too hard to teach" assertion either -- if you don't like teaching it, go
tell the GoF that they've got things all wrong :-).  The idea of a single
factory for all of them isn't quite so appealing -- every time we want to add a
new Struts API object, we need to go back and modify the standard factory
class, which is messy.

One interesting approach to this would be to add a responsibility to the
existing set of FooConfig objects, adding an appropriate create method to each.
 After all, if you want a specialized type of Action or ActionForm object,
you're probably going to need someplace to store extra configuration
information also, and the config object is exactly where you'd want to add
those properties.  Instead of createDynaActionForm() and
createDefaultActionForm(), then, we'd simply have createActionForm() on the
FormBeanConfig class, and it would do the right thing.  Using this approach,
configuring a specialized config bean class automatically configures a new
factory method as well, so you don't have to change two configuration settings
in struts-config.xml either.

An additional decision related to this whole condept, of course, is whether we
stick with the pure JavaBeans style object creation (zero-args constructor,
configure everything with property setters) or something like what Pico wants
(everything configured by arguments to the constructor).  I've dealt with
enough tools vendors in the last couple of years to be convinced that the
former (JavaBeans style) is *substantially* easier to build tools for, and
would therefore favor continuing that design pattern for any kinds of objects
(and object factories) that we create in the future.

Craig McClanahan

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

View raw message