For a large, heavy-duty-input data-driven web application, I would recommend C.
> C) [Conventional class] is NOT used, data form validation is defined within the > validation.xml and handled by struts, the Action class (or some > surrogate) then enforces all business rules. I've had deep discussions with other large teams in similar circumstances, and the consensus has been that (C) is the most safe, sane, and simple route. I would also recommend finely-grained DynaValidatorForms to ensure only the expected properties are captured and validated. Nowadays, I also use finely-grained Struts configs, so that each "pageflow" or "story" is represented by its own struts-config.xml and validator.xml. This requires a strong naming convention to be sure the members of each config overlaps, but it makes it very easy to work with each use-case or story independently. So instead of allocating a module or multiple struts-config to a "team" or "component", we allocate them to each use-case or story. You do end up with lots and lots of struts-configs, but if they are well-named and use strong conventions, finding what you need is actually faster and easier than pouring through several much larger files. You can see the trees within the forest. There also tends to be less "cruft" since each struts-config is cohesive and only contains the elements used by a given story. (I discovered finely-grained struts-configs as part of a spelunking session. I pulled out all the elements for a pageflow to figure out how it worked, and then realized this was a pretty cool way to handle struts-configs in general. My team calls it "config-behind-story".) The business rules validations are often better handled by a non-Struts component that can be used outside of Struts or shared by Struts applications. This validation can take place after the Action executes. The trick is to have the business-rules validator return messages that can be converted to Struts Action Messages. If we ever finish the migration to Commons Resources, this part will be cleaner. We may also see more uses of Commons Validator outside of web application frameworks. You might also want to look at Niall's extension <http://www.niallp.pwp.blueyonder.co.uk/> which could work itself into the distribution one day if LazyDynaClass is accepted by Commons BeanUtils <http://www.mail-archive.com/[EMAIL PROTECTED]/msg01720.html>. -Ted. >We are having an internal discussion about the best > use of struts for a large heavy-input data-driven web application. > > We have discerned 4 approaches in the way we can use Struts. Given > this example class: > > Class (form bean).... > Public class Person extends ???? implements java.io.Serializable { > protected String firstName; protected String lastName; protected > int wein = 0; } > > These are four types of Struts usage: > > A) Person extends ActionForm, and provides implementation for > validate() method - validate data form and data type enforcement, > and then validates some object level business rules before handing > off to Action class > > <form-bean name="Employee" type="com.merck.Person" /> > > B) Person extends ValidatorForm, and provides implementation for > validate() method - validate data form through against > validation.xml through struts, and then validate some object level > business rules before handing off to Action class. > > <form-bean name="Employee" type="com.merck.Person" /> > > C) Person is NOT used, data form validation is defined within the > validation.xml and handled by struts, the Action class (or some > surrogate) then enforces all business rules. > > <form-bean name="Employee" > type="org.apache.struts.validator.DynaValidatorForm" > <form- > property name="firstName" type="java.lang.String"/> <form-property > name="lastName" type="java.lang.String"/> > <form-property name="wein" type="java.lang.String"/> </form-bean> > > D) Person is a business object only implementing > java.io.Serializable with no knowledge of application space, data > form validation is defined within validation.xml handled by struts, > the Action class then enforces all business rules. > > <form-bean name="EmployeeForm" > type="org.apache.struts.validator.DynaValidatorForm" > <form- > property name="employee" type="com.merck.Person "/> </form-bean> > > I personally prefer C. It is my understanding that DynaActionForm > should be used as a "firewall" to collect all strings (to return > invalid data to the client), use the Validator to perform > client/server side validation, the Action then copies the form data > into business objects, and then invokes delegates to perform > business processing. > > Please feel free to be candid with your views. I appreciate your > time reading this. > > Thanks, --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
