> -----Original Message----- > From: Leandro Melo [mailto:[EMAIL PROTECTED] > Sent: Tuesday, September 07, 2004 5:48 PM > To: struts jakarta > Subject: ActionForm with all application attributes > > > Hi, > i sent this question yesterday, but as nowbody > answered me, i trying it again with a more > sifinificant title (sorry for the re-post). > Also, if i'm doing something terrible, i'd like to > know. > > Keeping in mind that more than one action form may > have to validate and/or reset the same fields, i > decided to this. > > I already have a MyBaseActionForm which incorporates > all > some methods that i need in my application. I don't > use Validator, as i prefer to use java classes for > validation ligth business logic. > > Now, i decided to add ALL fileds (setters and > getters) > i have in my application as private members of this > MyBaseActionForm. > > Then i created classes WebValidation and WebReset. > This classes have validate methods for all fields in > my application. These classes can access the fields > they need for each method because all my action > forms > extend the MyBaseActionForm, thus this WebValidation > and WebReset classes can call the setters and > getters > of an y action form to validate with the light > business logic i need. > > I got with this approach a centralized way and > "component" responsible for the validation. All my > action forms delegate the validate and reset methods > to the classes i mentioned. > > I'd like to briefly describe some nice > benefits of this approach. > > - With this approach i definetly solve my earlier > problem that i posted on question "1:N relationships - > ActionForm x DTOs".
Didn't see this post, but yes there could be 1 to many between ActinForm and DTO's, and this is not a problem. ActionForms directly represent what is on the screen, while DTO's represent your data. You have a 1-to-many relationship between screens and tables. > > - With this approach i got no coupling between my > ActionForm and DTOs. What do you mean by coupling? You still have to transfer data to and from the DTO. > > - With this approach i have a centralized validate > unit. It's very usual to have more than 1 action form > validating the same field, what may causes some > duplication and a harder maintenance. A central unit > of validation and resetting suits this problem very > well. The strtus validate stuff is centralized, and easier to configure. Doing it all in one class, means that at some point your going to have logic to handle special cases.... The more of these you have hte more complex the logic... Complex logic is directly related to the stability of your code. In addition I don't have to code the validations myself. Just specify what I want validated and I'm done. You could do the same thing, however you still have to glue it all together. > > - With this approach i can perform light business > validation that must be done in java code. So, for one > or more situation i could access some util classes > that do some validation for me. You can do this with custom validation classes and still achieve centralizations. Depending on what you mean by light business validation. I like consistency in where things are. Business rules in business layer, and validation in the view tier. A newcomer to the app would have to guess (yeah, sure they'll ask, maybe) where the code is supposed to go. > > - With this approach i have very small action forms > that basically has a validate and reset methods that > just delegate to the WebValidation and WebReset > classes. With the standard struts approach I have even smaller action classes.... no validate or reset methods. > > - With this approach i also have a central unit of > fields and their types, so if it's necessary to chance > them, i don't need to go through all the action forms > that have these fields. You can do this with a base action form. > > This approach will only work correctly if you don't > have fields with the same name in your application. > Naturally, this is not a drawback because forces you > to use a nice use of software engineering forcing you > to give significant names for the fiels. Not entirely true. I have several fields that get validated differently based on where they come from, or where the data is going (some customers will accept a phone number that is 10-30 numbers, -() and '.', others want a US phone number). Right now, I use a different form bean for each, and use a common base class for everything. The different child class allows for different completely different validations, which is what I need. Doing it your way would make this customization much harder, since I would have to sublcass the validation class too. With struts 1.2, I can use inheritance and make this even easier then the copy and paste I use now. > > Well, i'd appreciate comments (bad or nice ones) on > that. > > Thanks, > Leandro > > > > > > _______________________________________________________ > Yahoo! Acesso Grátis - navegue de graça com conexão de qualidade! > http://br.acesso.yahoo.com/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
