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]
