i've just finished a basic implementation but haven't had the time to document it (or create any subclasses that address your specific use case). i'm happy with the basic design of the pluggable strategy but now feel that the bean writing API may need revising (more on this later). i don't have the time to think about this now so i've decided to commit what i have so that people can give it a try and point out any improvements that could be made.
you need to grad the latest code from CVS HEAD and build it (using maven) or wait until the next nightly build. you then need to extend BaseMixedContentEncodingStrategy so the property you're interested in is encoded using CDATA (rather than character escaping).
(i'll say some words on the design now but probably any follow up discussions would be more appropriate on the developers list.)
i decided that it was most appropriate to implement this as a BeanWriter specific strategy (rather than including it as part of betwixt file) since it really doesn't make much sense for SAXWriter. this means that users are going to have to create strategy implementations that work which elements need to be encoded as CDATA. (maybe some volunteers might like to contribute some helpful implementations.) if this is a major issue and users would really like to be able to set this through the .betwixt file (or through registered element descriptors), then i'd prefer to use some kind of extensible additional property mechanism (which could be interpreted by the strategy) rather than add it directly.
the bit of the design i'm not particularly satisfied with is the way that beanwriter discovers the current element. i added a field but i'm leaning towards altering the API (once more) so that a context is passed in. this context would contain the element descriptor (and another other useful data that needs to be added later).
comments welcomed :)
- robert
On 24 Mar 2004, at 14:59, Nechiporenko, Maxim wrote:
Robert, thank you for the answer. I believe the plan you outlined in the
end of your message is acceptable.
Thanks, Max
-----Original Message----- From: robert burrell donkin [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 24, 2004 6:47 AM To: Jakarta Commons Users List Subject: Re: Betwixt appears to escape special characters
interesting :)
the standard use case for betwixt is to have properties containing real java values which are mapped from the xml by betwixt. that's why all characters are appropriately escaped.
AFAIK at the moment, there is no support for properties that need mapping to CDATA (since no one's ever presented a use case for this before). AIUI if you set '<error>Some Error</error>' as the property value then betwixt will correctly escape it. i'm not really clear what use case demands escaping through CDATA rather than by escaping each character. maybe someone could remind me of an occasion when CDATA sections are treated differently.
the easiest way to add this kind of feature would be to add settings that escaping to be ignored for some properties. there are a couple of drawbacks that i think i can see for this approach:
1. it leads to inconsistency between SAX pipelines and output to string. (the downstream SAX consumer must assume that the '<![CDATA[...]]/>' must already have been process from something like '<![CDATA[<error>...</error>]]>') 2. it leads to inconsistency between bean property setters and getters: when reading a bean, the section wrapping would already have been stripped by the xml parser. therefore, the bean would need to be able to cope with processing a plain <error>Some Error</error> into a CDATA section.
therefore it seems to me to be better to continue with the existing strategy. so, the property value would need to be '<error>Some Error</code>'. betwixt would then need to recognize that this needs to be escaped as CDATA (rather than through character escapes).
would this plan be acceptable?
- robert
On 23 Mar 2004, at 18:03, John Crossman wrote:
I am also interested in the answer here.
Maxim: How do you get certain elements to be given <![CDATA[ ]]/> treatment? And is it possible to only have CDATA applied when the contained text-value is HTML or equivalent? How do we control this in
the .betwixt file?
Thanks!
J.
-----Original Message----- From: Nechiporenko, Maxim [mailto:[EMAIL PROTECTED] Sent: Monday, March 22, 2004 10:41 AM To: [EMAIL PROTECTED] Subject: Betwixt appears to escape special characters
I am having trouble marshalling a JavaBean with one of its attribute values set to a text which is an XML string. It looks like Betwixt escapes special characters coverting them to ASCII. I have a JavaBean Foo.java, and I use Commons Betwixt to marshall JavaBean in XML. Here is what I am doing:
// JavaBean public class Foo { private String val = null;
public void setVal (String val) { this.val = val; }
public String getVal() { return this.val; } }
// Test program import java.io.StringWriter; import org.apache.commons.betwixt.io.BeanWriter;
public class test { public static void main (String [] args) { test t = new test(); t.doStuff(); }
public void doStuff() { Foo bean = new Foo(); bean.setVal("<![CDATA[<error>Some Error</error>]]");
StringWriter outputWriter = new StringWriter(); BeanWriter beanWriter = new BeanWriter(outputWriter); beanWriter.getXMLIntrospector().setAttributesForPrimitives(false); beanWriter.setWriteIDs(false); beanWriter.enablePrettyPrint(); beanWriter.write("foo", bean); System.out.println("XML: "+ outputWriter.toString()); }
The XML I am getting looks the following:
<foo> <val> <![CDATA[<error>Some Error</error>]]> </val> </foo>
when I would need it to be:
<foo> <val> <![CDATA[<error>Some Error</error>]] </val> </foo>
I have no issues marshalling this Bean using Castor. Any help on how to get Betwixt to produce the desired XML string is welcome.
Thanks, Max
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
