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]
