Your idea would certainly work. To avoid the overhead of introspection,
you'll probably want to do some caching of the introspection results (e.g.
the validate methods). A concern I have is whether subclassing from your
base validation class is a desired feature: unless you do some code
generation, you'll have to do it yourself and write the methods. Where does
the configuration come in?
Also, I think the naming convention would be more accurate and flexible if
it was based on the form name rather than the class name. This is with such
a naming convention that we have integrated our mapper framework with
struts: each ActionForm looks for a mapper named mapping.getNamed() +
"Mapper" and execute it if found.
Finally, I'm not sure what you mean by keeping validation and conversion
separate and why you would do so. My earlier postings were argumenting why
we should not dissociate them. In the case of our mapper framework, it
supports both, while still keeping them somewhat separate. The mapping steps
(validate/convert/transfer) can be executed all at once or selectively. In
the case of Form validation, validate and convert are done together for each
mapping (form values). In other contexts you could perfectly validate all
mappings (values) first, then convert them all in a separate step (so you
can do other things in between), and finally transfer.
Fr.
-----Original Message-----
From: Cook, Levi [mailto:[EMAIL PROTECTED]]
Sent: 26 June 2001 17:43
To: '[EMAIL PROTECTED]'
Subject: RE: Struts 1.1 TODO List -- Event and Listener Model
And now, for something completely different..
I officially withdraw my support for the JavaBeans validation/conversion
track :) I'd like to thank everyone for their input on this idea tho., if
nothing else I've learned quite a bit.
Besides, I might have another abstraction in mind now :) Its actually not
*my* idea becuase it occured to me as I was writing unit tests with JUnit.
For those of you familiar with JUnit, I'm basically thinking of something
like this:
com.myco.struts.ui.MyForm <<ActionForm>>
com.myco.struts.ui.MyFormValidation <<Validation>>
Where MyFormValidation is analogous to the JUnit TestCase. Essentially, I'd
like the ActionServlet to locate this class by a simple naming convention;
eg. form.getClass().getName() + "Validation". If found, it would load,
instantiate, setup(Serializable form) and run the objects command method
(eg. run()). The command method, in turn would introspect itself and execute
all the "validate" mothods. Each validate method would then be able to
record their respective errors into a member ActionErrors object. The
ActionServlet then retrieves any ActionErrors through the getErrors method.
Vatidation
+ setup(form Serializable) : void
+ run : void
+ getErrors : ActionErrors
Anyway, I'll post more on this later, just wanted to get the idea out there
for feedback (or criticism).
As a side note, I'm a proponent for keeping Validation and Conversion
separate, simply becuase I view each as significant potentially discrete
issues.
Regards,
Levi Cook
************************************************************************
The information in this email is confidential and is intended solely
for the addressee(s).
Access to this email by anyone else is unauthorised. If you are not
an intended recipient, you must not read, use or disseminate the
information contained in the email.
Any views expressed in this message are those of the individual
sender, except where the sender specifically states them to be
the views of Capco.
http://www.capco.com
***********************************************************************
