RE: ActionForm with all application attributes
Thanks, i`ll take a look at that in the next days!! --- Jim Barrows <[EMAIL PROTECTED]> escreveu: > > > > -Original Message- > > From: Leandro Melo > [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, September 08, 2004 10:25 AM > > To: Struts Users Mailing List > > Subject: RE: ActionForm with all application > attributes > > > > > > --- 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? > > http://struts.apache.org/api/org/apache/struts/validator/ValidatorActionForm.html > As opposed to ValidatorForm. > The following is from memory, but should be close. > Assuming the following struts-config.xml > blah blah > type="com.sssc.csr.web.forms.BorrowerDemographicsForm"> > blah blah >name="ChangeAddressForm" > validate="true" > type="com.sssc.csr.web.actions.ChangeAddressAction" > > scope="request"> > >path="changeAddress"> > > > > Normaly, your validation.xml would look like: > > blah blah. > > > Using the path mapping you would have the following > in your validation.xml: > blah blah > > blah blah. > > > AND, don't forget inherit from ValidatorActionForm, > as oppposed to ValidatorForm. > > - > 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]
RE: ActionForm with all application attributes
> -Original Message- > From: Leandro Melo [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 08, 2004 10:25 AM > To: Struts Users Mailing List > Subject: RE: ActionForm with all application attributes > > > --- 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? http://struts.apache.org/api/org/apache/struts/validator/ValidatorActionForm.html As opposed to ValidatorForm. The following is from memory, but should be close. Assuming the following struts-config.xml blah blah blah blah Normaly, your validation.xml would look like: blah blah. Using the path mapping you would have the following in your validation.xml: blah blah blah blah. AND, don't forget inherit from ValidatorActionForm, as oppposed to ValidatorForm. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ActionForm with all application attributes
--- 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 hav
RE: ActionForm with all application attributes
> -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. > > > > > --- 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 spec
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. 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 clas
RE: ActionForm with all application attributes
> -Original Message- > From: Leandro Melo [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 08, 2004 5:40 AM > To: Struts Users Mailing List > Subject: Re: ActionForm with all application attributes > > > Bill, wait a minute, i just thought on something. > I wouldn't matter if a hacker set a attributes in my > BaseActionFomr, if i don't use it to build my DTOs. I > mount my DTOs case specific, so i'd just ignore the > hacker set attribute. > But if this hacker set attribute is in my DTO, i agree > that i could get problems. But if this attribute is > present in the DTO it means that even if i was using > the traditional way this attribute would present in > the traditional ActionForm and, consequently, would be > suceptible to the same problem. > Got the point??? Why give them any hooks you don't have to? Sure today you're not using the field, what about tomorrow? If the field isn't there in the form, then struts won't copy the attacking value into it, and you won't have to worry about it at all. > > > --- Bill Siggelkow <[EMAIL PROTECTED]> escreveu: > > > Are all of your getters and setters public? If so, > > (which I assume is > > true), one disadavantage is that request parameters > > can be passed in > > that set stuff on the form that you may not be > > expecting. For example, > > suppose your uber form supports properties for 'foo' > > 'bar' and 'baz'. > > > > Let's say one form sets the first two properties -- > > from a GET you would > > see: > > > http://localhost/myapp/SubmitFooBar.do?foo=blah&bar=glob > > > > Now suppose some hacker comes along and does the > > following: > > > > > http://localhost/myapp/SubmitFooBar.do?foo=blah&bar=glob&baz=evilvalue > > > > Now, the property for baz has been set when you > > weren't expecting it to. > > > > - Bill Siggelkow > > > > > > Leandro Melo wrote: > > > > > 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". > > > > > > - With this approach i got no coupling between my > > > ActionForm and DTOs. > > > > > > - 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. > > > > > > - With this approach i can perform light business
RE: ActionForm with all application attributes
> -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
Re: ActionForm with all application attributes
True -- some people use bulk property setters like those provided by BeanUtils to move data from the ActionForm to the DTO -- I think that is primarily where you would need to be careful. Personally, I am not fond of the use of an uber form; it doesn't seem very object-oriented; however, I can see advantages for small applications. - Bill Siggelkow Leandro Melo wrote: Bill, wait a minute, i just thought on something. I wouldn't matter if a hacker set a attributes in my BaseActionFomr, if i don't use it to build my DTOs. I mount my DTOs case specific, so i'd just ignore the hacker set attribute. But if this hacker set attribute is in my DTO, i agree that i could get problems. But if this attribute is present in the DTO it means that even if i was using the traditional way this attribute would present in the traditional ActionForm and, consequently, would be suceptible to the same problem. Got the point??? --- Bill Siggelkow <[EMAIL PROTECTED]> escreveu: Are all of your getters and setters public? If so, (which I assume is true), one disadavantage is that request parameters can be passed in that set stuff on the form that you may not be expecting. For example, suppose your uber form supports properties for 'foo' 'bar' and 'baz'. Let's say one form sets the first two properties -- from a GET you would see: http://localhost/myapp/SubmitFooBar.do?foo=blah&bar=glob Now suppose some hacker comes along and does the following: http://localhost/myapp/SubmitFooBar.do?foo=blah&bar=glob&baz=evilvalue Now, the property for baz has been set when you weren't expecting it to. - Bill Siggelkow Leandro Melo wrote: 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". - With this approach i got no coupling between my ActionForm and DTOs. - 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. - 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. - 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 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. 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. 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] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ActionForm with all application attributes
Bill, wait a minute, i just thought on something. I wouldn't matter if a hacker set a attributes in my BaseActionFomr, if i don't use it to build my DTOs. I mount my DTOs case specific, so i'd just ignore the hacker set attribute. But if this hacker set attribute is in my DTO, i agree that i could get problems. But if this attribute is present in the DTO it means that even if i was using the traditional way this attribute would present in the traditional ActionForm and, consequently, would be suceptible to the same problem. Got the point??? --- Bill Siggelkow <[EMAIL PROTECTED]> escreveu: > Are all of your getters and setters public? If so, > (which I assume is > true), one disadavantage is that request parameters > can be passed in > that set stuff on the form that you may not be > expecting. For example, > suppose your uber form supports properties for 'foo' > 'bar' and 'baz'. > > Let's say one form sets the first two properties -- > from a GET you would > see: > http://localhost/myapp/SubmitFooBar.do?foo=blah&bar=glob > > Now suppose some hacker comes along and does the > following: > > http://localhost/myapp/SubmitFooBar.do?foo=blah&bar=glob&baz=evilvalue > > Now, the property for baz has been set when you > weren't expecting it to. > > - Bill Siggelkow > > > Leandro Melo wrote: > > > 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". > > > > - With this approach i got no coupling between my > > ActionForm and DTOs. > > > > - 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. > > > > - 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. > > > > - 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 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. > > > > 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. > > > > 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] > > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROT
Re: ActionForm with all application attributes
Bill, this is for sure a disadavantage. Do you see others Actually, we're suceptible to this avantage in all forms, but i agree with you that if i have a base form with all atributes the chances of things getting messed up is a log bigger. --- Bill Siggelkow <[EMAIL PROTECTED]> escreveu: > Are all of your getters and setters public? If so, > (which I assume is > true), one disadavantage is that request parameters > can be passed in > that set stuff on the form that you may not be > expecting. For example, > suppose your uber form supports properties for 'foo' > 'bar' and 'baz'. > > Let's say one form sets the first two properties -- > from a GET you would > see: > http://localhost/myapp/SubmitFooBar.do?foo=blah&bar=glob > > Now suppose some hacker comes along and does the > following: > > http://localhost/myapp/SubmitFooBar.do?foo=blah&bar=glob&baz=evilvalue > > Now, the property for baz has been set when you > weren't expecting it to. > > - Bill Siggelkow > > > Leandro Melo wrote: > > > 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". > > > > - With this approach i got no coupling between my > > ActionForm and DTOs. > > > > - 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. > > > > - 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. > > > > - 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 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. > > > > 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. > > > > 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] > > ___ 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]
Re: ActionForm with all application attributes
Are all of your getters and setters public? If so, (which I assume is true), one disadavantage is that request parameters can be passed in that set stuff on the form that you may not be expecting. For example, suppose your uber form supports properties for 'foo' 'bar' and 'baz'. Let's say one form sets the first two properties -- from a GET you would see: http://localhost/myapp/SubmitFooBar.do?foo=blah&bar=glob Now suppose some hacker comes along and does the following: http://localhost/myapp/SubmitFooBar.do?foo=blah&bar=glob&baz=evilvalue Now, the property for baz has been set when you weren't expecting it to. - Bill Siggelkow Leandro Melo wrote: 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". - With this approach i got no coupling between my ActionForm and DTOs. - 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. - 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. - 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 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. 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. 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]
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". - With this approach i got no coupling between my ActionForm and DTOs. - 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. - 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. - 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 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. 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. 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]
