If the Transformation interface translates objects to and from
Strings, how is it different than PropertyEditors?
-will
Ron Smith writes:
> 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
>
