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]