Jim, all the code i`m talking about is inside a Base Action Form. It seems the you`re thinking that my code is inside a action, aren`t you?? Maybe a misundertanding, maybe mine, maybe yours.
So, i agree with some of your comments, but not on all of thems. In fact, i`m gonna to take a look about this customized classes to use with validator. --- Jim Barrows <[EMAIL PROTECTED]> escreveu: > > > > -----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] > > _______________________________________________________ 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]
