File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Struts and the fly likes ActionForm, is bad design? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Frameworks » Struts
Bookmark "ActionForm, is bad design?" Watch "ActionForm, is bad design?" New topic
Author

ActionForm, is bad design?

Jacky Chow
Ranch Hand

Joined: Sep 01, 2002
Posts: 63
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?


Jacky
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4462
    
    6

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 - [How to Ask Questions] [How to Answer Questions]
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4462
    
    6

BTW, sample chapters of the book are available here
Neal Ford
Author
Ranch Hand

Joined: Oct 23, 2003
Posts: 82
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.


Neal Ford<br />Author, <i>Art of Java Web Development: Struts, Tapestry, Commons, Velocity, JUnit, Axis, Cocoon, InternetBeans, WebWork</i><br /><a href="http://www.nealford.com" target="_blank" rel="nofollow">www.nealford.com</a>
Svetlana Koshkina
Ranch Hand

Joined: Jul 08, 2003
Posts: 108
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
Ranch Hand

Joined: Sep 01, 2002
Posts: 63
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
Ranch Hand

Joined: Nov 27, 2002
Posts: 451
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 ]

kktec<br />SCJP, SCWCD, SCJD<br />"What we observe is not nature itself, but nature exposed to our method of questioning." - Werner Heisenberg
Jacky Chow
Ranch Hand

Joined: Sep 01, 2002
Posts: 63
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!
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: ActionForm, is bad design?