On Wed, 2004-07-14 at 00:09, robert burrell donkin wrote:
> On 13 Jul 2004, at 16:51, Henning P. Schmiedehausen wrote:
>
> > Hi,
>
> hi henning
Hi,
> XMLIntrospectorHelper is very limiting and will hopefully be completely
> deprecated sometime soon. the primitives concept needs to be extended
> into the more flexible concept of simple type. (the simple type concept
> is more often used in the xml-object binding community.) the refactored
> code with improved design has been merged into HEAD now and some of
> these changes in this direction have been made (but i've lost track a
> bit since i'm currently juggling a number of releases at the moment).
> just FYI the plan is to cut a 1.6 based on the improved design very
> soon.
This sounds nice. I felt that the XMLIntrospectionHelper is not flexible
enough to fit to all needs. Getting it pluggable through a strategy
object would help here.
> > In the end I came up with the attached patch, which works fine for me
> > (it might not
> > be ideal, because the resulting XML contains the raw sew^Wbinary data
> > if you write the bean out.
>
> i'm not sure i parse this correctly. (it's a little late, so it might
> be me.) care to expand?
It's simple. With this patch, when you introspect a bean that contains
a byte [] array, you might end up with <foo bytes="random noise right
from the bean"> without any escaping or CDATA encapsulation. Most of the
times, this is not what the developer wants (and it might not be valid
XML). In my application I have a custom converter which does
import org.apache.commons.codec.binary.Base64;
public class CustomConverter
extends DefaultObjectStringConverter
{
public String objectToString(Object object, Class type, String flavour, Context
context)
{
if (object instanceof byte[]) {
return new String(Base64.encodeBase64Chunked(object), "ISO-8859-1");
} else {
return super.objectToString(object, type, flavour, context);
}
}
public Object stringToObject(String value, Class type, String flavour, Context
context)
{
if (type.equals(byte [].class)) {
return Base64.decodeBase64(value.getBytes("ISO-8859-1"));
} else {
return super.stringToObject(value, type, flavour, context);
}
}
}
So I get my byte arrays converted into base64 Strings.
[...]
> > I was wondering if it would be more clever to allow the user to
> > explicitly set the primitiveType property of the element descriptor
> > from the .betwixt file. I found no way to do so, though and I already
> > had this patch which works for me.
>
> the answer is yes but the concept needs to move from a fixed list of
> primitives to a flexible, configurable (with strategy plugin as well as
> property) simple type binding. this is definitely on the to-do list but
> i'm right in the middle of managing various release cycles so i'm not
> sure when i'll get the chance to look at this.
>
> it should be pretty straightforward and i'd be willing to help explain
> the new design, so if you'd like to volunteer to take this on, that
> would be great.
I will take a look. No promises, though.
>
> > Anyway, here is the patch, discussions welcome. ;-) This is against
> > CVS HEAD. I would volunteer to write an Unit test for it if has a
> > chance to get applied.
>
> there is every chance that a fix for this would get committed with a
> unit test :)
>
> i have an idea that the patch is against the 0.5 code base (but i could
> be wrong since i haven't looked into this in detail). please set my
> suspicious mind at rest by updating before you start getting into this.
Well, it is against CVS HEAD, which identifies itself as 0.6-dev in the
project.xml. Is there another version?
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
[EMAIL PROTECTED] +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
"Fighting for one's political stand is an honorable action, but re-
fusing to acknowledge that there might be weaknesses in one's
position - in order to identify them so that they can be remedied -
is a large enough problem with the Open Source movement that it
deserves to be on this list of the top five problems."
--Michelle Levesque, "Fundamental Issues with
Open Source Software Development"
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
