PropertyEditors only do that as a side-effect. They are designed
to take the value out of the bean, hold it, allow modifications to
the value, and then allow the application to put it back when editing
has finished. There is a lot of overhead involved in that if all you
want is text conversion. Besides, property editors don't have to
implement the string-based methods... in which case they won't even
do the conversion for you.
-Paul Speed
William Shulman wrote:
>
> 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
> >
