You may remember some of my earlier postings about a mapper framework that we use as a
validation framework. I now have the support in my company to make it open source.
However, I first would prefer to:
1- Invite the community to realize that a validation framework, definitely required in
Struts, is only part of a larger requirement.
2- Propose the extension of the scope of the TO DO item for validation so that is does
a bit more than just validation but also convert the value and transfer them to where
they should end up.
I know I've already approached this topic in my previous postings, but I there hasn't
been much follow up on this. However I still believe those that have developed web
applications with Struts have been confronted to the same problems we have been trying
to solve. So instead of submitting a big zip file that may or may not get interest, I
first would like to share the reasons that led us to developing the mapper framework.
In our company, after evaluating a few options, we have chosen Struts as the base
framework for developing web applications. We have developed our own simple extensions
to Struts in order to provide added support for things like i18n and transaction
integrity. Form validation was also a top item in our list of needed extensions, but
looking at the Struts 1.1 TO DO list we decided to wait and see what the community
would come up with. For one of our customer project, we have looked at the validation
framework from David Winterfeldt in order to implement form validation. We were very
attracted to that framework because it offered configuration-based validation and also
client-side validation. However beyond the simple need to validate form properties, we
also needed to do type conversion (text->object) on each field and populate another
bean (a command bean) with the converted values. Having a framework that only
addressed the validation part meant that we would still need to do a lot of custom
coding in order to convert values and populate our command beans. And in addition to
this, we also needed to do type conversion and populate presentation beans when
receiving result messages from the backend, which means even more custom coding.
I think by now you should understand and hopefully agree with me that validation is
actually only the first part of larger need: once values have been validated, you need
to do something with them. Whatever is needed to do, it should not be the
responsibility of the ActionForm. The latter should remain a View object that is only
a placeholder for user input. Business logic should be separated into another set of
objects. Actions seem to be a good place for implementing this business logic. However
doing so ties the logic to the web application framework in a way that makes the reuse
of this logic outside of a web application difficult. So a good application architect
would usually factor this business logic into another set of objects that is not
dependent from the web application. Often these objects are actually just sending
requests to a backend where the real business logic resides. But whatever these
objects are (the real Model, a PreparedStatement, or a proxy to a Model layer
implemented on another server), the point is that these are objects which need to be
initialized and populated with the user input.
Coming back to our project: we have an EJB backend accessed with a messaging
framework: you send command messages (objects), and you get result messages (objects).
And of course we wanted to avoid lots of custom code in our actions because it's
tedious, not so fun to write, and increases the maintenance burden (more lines of
code). So we took the decision to develop the mapper framework. What we now have is
used almost all over the place in the application we're developing, for the things I
mentioned above: validation, type conversion, and bean population, and for both
directions: forms -> command messages and result messages -> presentation beans. The
code in our Actions.perform() has decreased dramatically to just a few things. When we
get to the Action, the ActionForm.validate() has successfully validated the user input
with its mapper. In the Action.perform(), all we do is to ask the same mapper to
create the command message and populate it with the converted values, send this object
to the backend, ask another mapper to process the result message, and then forward to
the JSP.
Now that I have explained why validation is just part of a larger story, one might say
that a validation-only framework is a good start anyway. The problem with that
approach is that actually validation and conversion can be one and the same thing: if
you are able to convert a value into something else, this is at least partly
validating the value. Using the SimpleDateFormat class to create a Date object from a
String value will fail if the string is not in the proper format and does not contain
proper data values. So the point is that we should not dissociate validation from type
conversion. In some cases the validation is completely fulfilled by a successful
conversion, in other cases there is no need to convert but only to validate, and in
some other there is no need to validate or convert.
By looking at recent posting I think already most of us agree with the fact that the
validation framework should also be able to convert values. I don't think I really
need to convince people on this. The real extension that I want to propose to the
current scope for validation is the ability to transfer the converted values to their
real destination: most likely in a property of another object. Think about it: how
much more is it? If the validation and conversion are automated, no custom coding is
required for this anymore. But then in the current scope you still need to extract
those validated/converted values and, as I explained before, use them to populate
other objects. Automating the population of other objects with converted values is not
such a big effort when using PropertyUtils, we just have to specify the destination
object and the recieving property names at the same place where we specify the
validation/conversion. If some of you still think that just a validation/conversion
framework is again enough as a starting point, then think about it again: how much
more is it have the transfer functionality compared to the lines of custom code you'll
have to write to populate other objects with the converted values?
Having a validate/convert/transfer framework is really what we have tried to achieve
with the mapper framework. Because it does the job quite well and has increased our
productivity, I felt more compelled to write our story rather than just sending a big
zip file with the source. Whatever the Struts validation become, I think a framework
similar in scope to ours would really benefit to those developing applications with
Struts, and would make the Struts offering even more attractive.
If with this posing I also created an interest in making our mapper framework open
source, then great. I started to develop it 6 weeks ago and there are plenty of room
for improvements. For example it does not generate client-side javascript, it is still
creating lots of object at run time (no object recycling), and it only works from one
single configuration file (a bottleneck when using a repository within a large team).
So making it open source could be a great way to improve it and could give a kick
start for the Struts validation framework.
If you want to know more about the mapper, I invite you to read some of my earlier
postings, in which I also sent a sample configuration file. The mapper framework has
been developed independently from the Struts MVC classes. It is only dependent on
these utility packages:
- Struts PropertyUtils
- Struts Digester (and therefore an XML parser - Xerces of course :)
- The Regexp package from Jakarta (used in one validator )
- JavaCC/JJTree for parsing custom validation rules
Some of the logic for digesting the XML config file required some extensions to the
PropertyUtils and Digester. The PropertyUtils extension is for supporting what we have
called 'string keyed' properties, which are properties with accessors of the form
getProperty(String key) and setProperty(String key, Object value). The extensions to
the digester were for supporting the resolution of system entities (only public
entities can be resolved at present), and for adding convenience methods in order to
add our own rules to digester. The new rules we use are called SetTopNow, SetNextNow,
SetPropertyFromAttribute, SetInitFromObjects, CallMethodNow, etc (hopefully these name
gives you a rough indication of what they do).
If the interest is there, I can submit the code (although I'd prefer waiting another
week to finish some doc). But I don't think it should be within the Struts project. I
also don't think the strutsx would be an ideal place either because as I said it does
not depend on Struts, only a bit now because the PropertyUtils and Digester are still
part of Struts. I'm more thinking of the Jarakta commons since it is more generic in
nature and is has been built on top of things that will be transferred into the
Jakarta commons. The other reason why it is better placed in the commons is because it
is actually a generic validate/convert/transfer framework which can also have an
interesting value for other types of applications, not only for web developement. For
example it could be used in a file handler in order to validate each record and
produce a message object so be sent to a backend. With the ability to generate code
out of the configuration file, performance would be improved by avoiding reflection
and could be used for server applications with higher performance requirements. Again
lots of things an open source community can do...
François Rey
mailto:[EMAIL PROTECTED]
--
_______________________________________________
Get your free email from http://mymail.altavista.com
