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?
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>
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)
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.
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.
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.
kktec<br />SCJP, SCWCD, SCJD<br />"What we observe is not nature itself, but nature exposed to our method of questioning." - Werner Heisenberg
Destroy anything that stands in your way. Except this tiny ad:
The Low Tech Laboratory Movie Kickstarter is LIVE NOW!https://www.kickstarter.com/projects/paulwheaton/low-tech