Stephen,
You are absolutely right. xml file generated by
XMLEncoder is very unfriendly for human reading. Even
without using mapping file, castor can generate much
more friendly xml. Below are the xml files generated
from the same sample object:
Xml generated by XmlEncoder:
<?xml version="1.0" encoding="UTF-8"?>
<java version="1.4.2_01"
class="java.beans.XMLDecoder">
<void property="owner"/>
<object class="rms.common.persistency.PolicyStore">
<void property="PolicyTemplate">
<object
class="rms.common.persistency.PolicyTemplate">
<void property="interval">
<int>1</int>
</void>
<void property="retry">
<int>2</int>
</void>
<void property="timeout">
<int>3</int>
</void>
</object>
</void>
</object>
</java>
Xml file generated by castor:
<?xml version="1.0" encoding="UTF-8"?>
<PolicyStore>
<PolicyTemplate retry="2" interval="1"
timeout="3"/>
</PolicyStore>
--- Stephen Bash <[EMAIL PROTECTED]> wrote:
> Bin-
>
> I personally have never used XMLEncoder, so please
> take my words with
> a grain of salt. Looking at the API specification,
> XMLEncoder appears
> similar to other XML serialization tools for Java
> (XStream, JSX, etc).
> In my experience most of these tools don't provide
> much control over
> the appearance of the XML, they may or may not
> provide validation
> during marshalling/unmarshalling, and they don't
> provide a good way to
> tie in an external XML schema to the Java object
> model.
>
> I personally prefer Castor to these other tools
> because I get a large
> amount of control over how my XML appears after
> marshalling a Java
> object model. If I want to (not that I do it as
> often as some) I can
> have Castor create Java code from an XML schema.
> Castor can validate
> XML via a schema during unmarshalling, and with
> correctly coded
> ClassDescriptors, validate the object model during
> marshalling.
>
> All of the above factors are important to me because
> I work in an
> environment of prototypes -- development timelines
> are short, and
> there isn't a lot of time to build helper apps.
> Rather than building
> a GUI that reads the XML and allows a user to modify
> objects before
> running the code, the general understanding is that
> the user will
> simply modify the XML. With some of the other
> tools, that might be a
> tall order, but with Castor I can make my element
> and attribute names
> clean, concise, and understandable. In other
> environments, the XML is
> never looked at by a human, and so what it looks
> like doesn't matter
> much. In that case, a fast, simple serialization
> method might be of
> more use.
>
> To me, Castor is about control of the XML.
>
> If you have further questions, feel free to ask. I
> feel a little
> funny getting up on the soapbox, so I think I'd
> rather step down and
> answer more direct questions :-)
>
> Thanks,
> Stephen
>
>
> On 4/12/06, bin lin <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > Our project is in the middle of selecting a tool
> for
> > persistence service.
> >
> > Anyone can give or point me to the brief
> comparision
> > between castor xml and JDK XMLEncoder, so I can
> > convince others to use castor?
> >
> > Thanks
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam
> protection around
> > http://mail.yahoo.com
> >
> > -------------------------------------------------
> > If you wish to unsubscribe from this list, please
> > send an empty message to the following address:
> >
> > [EMAIL PROTECTED]
> > -------------------------------------------------
> >
> >
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
-------------------------------------------------
If you wish to unsubscribe from this list, please
send an empty message to the following address:
[EMAIL PROTECTED]
-------------------------------------------------
