struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ron Smith <ron.sm...@rpsenterprises.com>
Subject Re: Proposed feature: Bean property transformations
Date Tue, 05 Jun 2001 05:11:40 GMT
I like the idea of combining transformations with some validation
logic.  After all, you commonly validate the contents of a String by
trying to transform it into some other data type.
I'm also interested in the discussions going on about client side
validation and locale/language specific validation/presentation
although I haven't looked at it that closely.

Like you, this is something I could use right away, so I'm probably
going to work on putting something basic together pretty soon.

I was thinking of having a Transformation interface that supported
transforming an object from its primary form to a secondary form -
for instance transforming a Date object into a String.  This would
be a forward transformation.  The Transformation interface would also
support transforming an object from its secondary form to its primary
form (e.g. String to Date) - a reverse transformation.
Although validation would be implicitly
done as a part of transformation, there'd be a seperate validate(Object) function
that could be called to just validate an object in its secondary form (e.g.
a String that holds a date representation).
I'd have various types of transformation classes to support the different
data types in the application.  Some would be fairly generic and reusable
and some would be pretty application specific.

I'd probably have the ActionForm have two sets of attributes for its
fields - the fields in String form as they came in the HTTP request, and
the fields in their primary data type form.  This is because I usually don't
have a simple mapping between a form's fields and the attributes of a
business entity bean, so It doesn't help me to try to transform into
another bean's fields,  might as well keep it all in the same ActionForm
object.
It'd be nice to have something automatically apply the correct
transformations to each field in the  ActionForm and generate error
messages for any transformations/validations that failed.

I'd also like to have something generic enough that it could be used
in non-servlet type of applications as well.


Ted Husted wrote:

> What I'm missing is a comprehensive, general package for converting data
> types and formatting properties for presentation. Most of this
> functionality is available somewhere in java and javax space, but it's
> spread around.
>
> What would be most useful, I think, is a single, generic package that
> provided
>
> (1) validation of Strings using regular expressions (a la David
> Winterfeldt's servlet), with direct support for native and JDBC
> datatypes,
>
> (2) binary to String and String to binary conversions for all native and
> standard types, and support for adding others,
>
> (3) given a formatting specification ("00#.##") and data of any
> supported type, return a formatted presentation String,
>
> (4) support for locale-senstive transformations with (3),
>
> (5) support for extending the formatting specification for unusual
> circumstances, and
>
> (6) provide simple date-calculation methods and a countdown presentation
> format (seconds, minutes, hours, or days from now until then).
>
> We could then use this helper object during the validation cycle to
> convert incoming Strings to the other types needed by business-logic
> objects, AND pass through the functionality from a <bean:writeTransform
> > tag, that could pull a property from a given bean, transform it, and return a formatted
String for direct use by the view.
>
> If there is not something like this already out there, I've very
> interested in getting started on this package, since I really, really
> need it for my own projects. Could be a nice addition to the Commons ...
>
> I'm cross-posting this to Struts user in case someone can suggest a
> package that already provides this functionality.
>
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel 716 737-3463.
> -- http://www.husted.com/about/struts/
>
> Ron Smith wrote:
> >
> > I've been thinking of implementing this feature lately and I haven't
> > seen it proposed on this list yet.  Any comments?
> >
> > Summary:
> > Provide a means to flexibly plug in transformations that could
> > be applied to JavaBean properties for presentation in a JSP page.
> > What transformation to apply to which JavaBean property
> > is specified in the Struts JSP tags (e.g. bean:write).
> > Transformations are Java classes that are responsible for taking
> > a JavaBean property or any other Object, applying whatever
> > transformation, and returning the transformed Object for
> > presentation in a JSP page.
> > Some example transformations are to format a date in a specific
> > format, format decimal numbers, or even to sort a collection in
> > a particular order before iterating over the collection's objects.
> >
> > Motivation:
> > Separating business entity code from presentation-specific code
> > is a good thing.  Consider a business entity class called Order.  If
> > we want to display the orderPlacedDate attribute in 4 different
> > date formats on a JSP page, we could add 4 different methods to
> > the Order class to support these 4 different formats.  But we quickly
> > end up with a very cluttered Order class and the Order class is too
> > coupled to the presentation details.
> > One approach I've used is to create presentation wrapper classes
> > which hold references to the business entity objects and are
> > responsible for all of the presentation specific formatting.  The
> > JSP pages access the presentation wrapper classes and not the business
> > entity classes.  For sites that access many different business entity
> > classes, this can become very tedious.
> > A better approach would be to be able to plug-in specific types of
> > presentation transformations to be applied to specific JavaBean
> > properties that are to be displayed in a JSP page without having to
> > create unecessary wrapper classes.
> >
> > Details:
> > Transformations are coded in transformation classes, all of which
> > implement
> > a Transformation interface.  This interface has one public method:
> > Object transform(Object inObj)
> > This method is responsible for applying whatever transformation is
> > needed
> > to the passed in object and returning a transformed version of the
> > object for presentation in a JSP page.
> > The transformation objects would be created at initialization based on
> > the
> > configuration file, and could be initialized with some parameters from
> > the
> > configuration file (e.g. the date format string to be used for a date
> > transformation).  Each transformation has a name associated with it, and
> > is
> > registered in a hash table based on the name.
> >
> > Some of the Struts custom JSP tags would be modified to take an
> > additional
> > transformation parameter which indicates what transformation is to be
> > applied.  For example:
> >    <bean:write name="order" property="orderPlacedDate"
> >      transformation="shortDateFormat"/>
> > In the above example, the orderPlacedDate property is retrieved
> > from the order bean, then the Transformation named "shortDateFormat"
> > is looked up in the transformations registry, and applied to the
> > property.  Whatever was returned by the transformation is what gets
> > displayed on the web page.
> >
> > Another benefit is that because the transformation objects exist
> > throughout the life of the application, some objects such as DateFormat
> > and NumberFormat can be cached in the transformation objects for
> > efficiency purposes.
> >
> > There's more details, but that's the basic idea.
> >
> > Ron


Mime
View raw message