Erik,
Thanks for your suggestion. JXPath looks very interesting but I'm not sure
it would solve our problem since it's not clear how we could specify a
JXPath object for each property on the page. What we want to do is along of
the lines of the following:
Say there's a Bean A with X getX() and setX ( X ). In the JSP itself we'd
like to specify the mechanism to convert X to and from a string. We want to
do this in the JSP since there may be many ways to view an instance of X.
We would expect to build a bunch of converter classes that do
String toString ( X, HTTPServletRequest ) and
X fromString ( String, HTTPServletRequest )
for each different conversion. We don't want to add methods to A to do this
as A should know nothing about presentation of X or about servlets.
We can use the existing pattern A.X to access X from A. That's okay for us
and we don't need anything more sophisticated. We don't want to add adaptor
methods to A that will convert X for two reasons. One is that we would need
another A for every different presentation of X. Second is that there may
be many instances of X in an object graph that starts with A.
Lastly, the conversion needs information in the ServletRequest since there
is context information there that will drive the conversion. The problem is
that in the current code, the conversions are done in different places and
span BeanUtils, ConvertUtils and RequestUtils, so its hard to find a
solution that won't be brittle to potential changes in these files.
Thanks,
Viral
-----Original Message-----
From: Erik Worth [mailto:[EMAIL PROTECTED]]
Sent: Thursday, September 27, 2001 1:04 PM
To: [EMAIL PROTECTED]
Subject: RE: Data conversion
Hi Viral,
I am using the Capco Mapper for data conversion because it basically allows
you to map from one abritrary structure to another. I am not using the
standard bean getters and setters, but rather setters and getters that use
JXPath (http://cvs.apache.org/viewcvs/jakarta-commons/jxpath/). The Capco
Mapper is highly extensible and can be extended (via sub-classing rather
than editing the original source) to transform virtually anything. I am
able to convert from one bean to another, an XML DOM tree to bean hierarchy
(and vice versa) and from one DOM tree to another (had to write my own
getters and setters for XML DOM traversal, but that was no big deal). You
can craft Converters that leverage java.text.MessageFormat to piece together
new strings from a resource bundle and some arguments, render a
java.util.Data according to a simple data format patter, or extract
information out of a string using regular expressions. The architecture is
very flexible and well thought out. The only problem I have seen with it is
that it references the old struts utilities that have now been moved to
commons.
-- Erik.
-----Original Message-----
From: Viral Tolat [mailto:[EMAIL PROTECTED]]
Sent: Thursday, September 27, 2001 12:13 PM
To: [EMAIL PROTECTED]
Subject: Data conversion
Is there any intent to modify the code to centralize conversion of
strings to objects and reverse? Currently, ConvertUtils is used to
convert strings to primitive objects, however, toString is used to
convert the object to a string.
We'd like to integrate in a data conversion framework but to do this
cleanly we need a cental place where all data conversion happens. In
addition, we'd need to be able to access the request or page context in
order to provide custom conversions on a per page basis.
We've looked at the transformations extension and the Capco Mapper,
however, we don't see how the transformations can be used with html:text
tags to provide data conversion from strings to objects since the Tag is
not involved at all in this process.
Thanks
