--- Jim Barrows <[EMAIL PROTECTED]> escreveu: > > > > -----Original Message----- > > From: Leandro Melo > [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, September 08, 2004 9:48 AM > > To: Struts Users Mailing List > > Subject: RE: ActionForm with all application > attributes > > > > > > 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. > > No, I understood you to have it in a Base Action. > > > > > 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. > > Another trick, is to use the same AcitonForm class, > but call it different things. Since validator will > work by name, and not by class you can customize > based on that alone. You can also validate a form > by action mapping, rather then by form name.
Would you mind showing an example on how to do that? > > --- 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. > > > > > > > > === message truncated === _______________________________________________________ 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]
