Revision 1 as of 2005-03-22 05:48:35
missing edit-log entry for this revision
converted to 1.6 markup
|Deletions are marked like this.||Additions are marked like this.|
|Line 11:||Line 11:|
|From a Core ["J2EE"] Patterns Catalog perspective, Struts is most like a||From a Core [[J2EE]] Patterns Catalog perspective, Struts is most like a|
|Line 27:||Line 27:|
|[http://jakarta.apache.org/struts/faqs/newbie.html#actionForms Newbie FAQ]||[[http://jakarta.apache.org/struts/faqs/newbie.html#actionForms|Newbie FAQ]]|
|Line 31:||Line 31:|
|[http://jakarta.apache.org/struts/userGuide/building_controller.html#action_form_classes User Guide]||[[http://jakarta.apache.org/struts/userGuide/building_controller.html#action_form_classes|User Guide]]|
(From 8/30/2003 struts-user posting by TedHusted.)
When discussing patterns, like "View Helper" and "Context", it's important to remember that these are *patterns* not architectural elements. In an implementation, a class will often use several patterns.
From a Core J2EE Patterns Catalog perspective, Struts is most like a Service to Worker. It combines several simpler patterns, like Front Controller, Application Controller, and View Helper. But in each case, more than one class is used to fulfill each of these roles. The ActionServlet and Request Processor serve as the Front Controller, the ActionMappings and Actions comprise an Application Controller, and the ActionForm and Server Page (with any associated taglibs or tools) act as the View Helper.
An ActionForm may represent *input* that a business object requires, but an ActionForm is not itself a business object. As it stands, Actions and ActionForms are coupled to Struts and the web layer and should not thought of as proper business classes.
For more about ActionForms generally, see