ActionForm, is bad design?

[Jacky Chow]

I think ActionForm in Struts is not good, it makes the form data objects bind to Struts, I think it should use general JavaBean classes that do not extend ActionForm, any opinion?

[Junilu Lacar]

Section 5.1.2 of AOJWD touches on this a bit. If you want to avoid getting tied in too much with the framework, you can use Transfer Objects (Value Objects in the book)

[Junilu Lacar]

BTW, sample chapters of the book are available here

[Neal Ford]

Originally posted by Jacky Chow:
I think ActionForm in Struts is not good, it makes the form data objects bind to Struts, I think it should use general JavaBean classes that do not extend ActionForm, any opinion?

There are several approaches to avoid coupling the Struts ActionForm into your entity classes. I cover a couple in my book, and Husted's book covers 6 in all. It boils down to a question of convenience vs. architectural purity. It is more convenient to directly sub-class ActionForm, but there are better ways that aren't quite so convenient.

[Svetlana Koshkina]

ActionForm is presentation layer, so we used to say, you tie it to some framework that really make your life MUCH easier. In every book advertising struts or some other framework you find that it was clearly stated that it's very important to keep presentation separate from persistency and buisness layers. So it's up to you
Shortly, it's not bad design at all: just an opposite - it shows how you are up to date AND AWARE.
i have book on how to make custom tags, in project i am working on currently, i did not have a single minute to use my previous experience fully and be comfortable: always new quirks and stuff, but i never had an urge to make custom tags (is it not a blessing in itself?). Who cares? It is just matter of dropping a few jars in your lib.

Regards

[Jacky Chow]

Originally posted by Junilu Lacar:
Section 5.1.2 of AOJWD touches on this a bit. If you want to avoid getting tied in too much with the framework, you can use Transfer Objects (Value Objects in the book)

The Value Objects in the section you mentioned is the common way to use ActionForm, it still extends ActionForm
Junilu, the link you provided seems not work now, here is another link: http://www.manning.com/catalog/view.php?book=ford&item=chapters

Originally posted by Svetlana Koshkina:
Shortly, it's not bad design at all: just an opposite - it shows how you are up to date AND AWARE.
i have book on how to make custom tags, in project i am working on currently, i did not have a single minute to use my previous experience fully and be comfortable: always new quirks and stuff, but i never had an urge to make custom tags (is it not a blessing in itself?). Who cares? It is just matter of dropping a few jars in your lib.

I still think it's not a good design, surely the Struts makes our life MUCH easier, but it might make my life MUCH MUCH easier if it support JavaBeans that do not extend ActionForm :roll:
In my previous project, I developed a web application that need to update existing EJB objects, the web application wraps some ActionForm objects to existing JavaBean objects, and then pass them to Session object, I think if the Struts framework supports JavaBeans that does not extends ActionForm, then I can use the existing JavaBeans directly!

Originally posted by Neal Ford:
There are several approaches to avoid coupling the Struts ActionForm into your entity classes. I cover a couple in my book, and Husted's book covers 6 in all. It boils down to a question of convenience vs. architectural purity. It is more convenient to directly sub-class ActionForm, but there are better ways that aren't quite so convenient.

Neal, thanks for your reply, I am happy to hear there are so many ways to solve this problem
[ February 13, 2004: Message edited by: Jacky Chow ]

[Ken Krebs]

Jacky,
I agree with you. A good alternative to the Struts webapp framework is Spring which addresses the very problem you mention very nicely (note the last paragraph).
From Juergen Hoeller, one of the lead developers:

First of all, note a very basic issue: In contrast to Struts or WebWork, Spring is an application framework for all layers, offering a bean configuration foundation, a JDBC abstraction framework, abstract transaction support, etc. It is a very non-intrusive effort: Your application classes do not need to depend on any Spring classes if not necessary, and you can reuse every part on its own if you like to. From its very design, the framework encourages clean separation of tiers, most importantly web tier and business logic: e.g. the validation stuff does not depend on web controllers. Major goals are reusability and testability: Unnecessary container or framework dependencies make this very hard.
Spring's web framework is designed around a DispatcherServlet that dispatches requests to handlers, with configurable handler mappings, locale resolution, and view resolution. The default handler is a very simple Controller interface, just offering a "ModelAndView handleRequest(request,response)" method. This can already be used for application controllers, but you will prefer the included implementation hierarchy, consisting of AbstractController, AbstractCommandController, MultiActionController, SimpleFormController, AbstractWizardFormController. Application controllers will typically be subclasses of those. Note that you can choose an appropriate base class: If you don't have a form, you don't need a FormController. This is a major difference to Struts.
You can take any object as command or form object: There's no need to implement an interface or derive from a base class. Spring's data binding is highly flexible, e.g. it treats type mismatches as validation errors that can be evaluated by the application, not as system errors. So you don't need to duplicate your business objects' properties as Strings in your form objects, just to be able to handle invalid submissions, or convert the Strings properly. Instead, it's often preferable to bind directly to your business objects. This is another major difference to Struts which is built around required base classes like Action and ActionForm.

Spring has just released version 1.0RC1 and a fairly quick transition to a the first production release is expected fairly soon (in March).
[ February 13, 2004: Message edited by: Ken Krebs ]

[Jacky Chow]

Ken,
Thanks for your useful information, the Struct framework is the only one I have used, I know there are many frameworks for web development, Neal's book is good for me to learn other frameworks, but the book seems it does not cover Swing! so really thank you very much!