You might also want to look at Quick. It doesn't do serialization, which preserves the
specifics of the classes used to hold the
data. Rather, it supports bi-directional transformations between an XML language of
your own design and your own classes.
There are a number of restrictions. Data must be accessible as public variables or
bean properties. When moving from XML to objects,
you need public 0-parameter constructors.
Most important, the elements must corrispond directly to the objects. This may mean
that you need to transform the XML if you want
to use a different object model.
Documentation is available on a wiki wiki, where you can add your own comments and
insights: http://quickutil.sourceforge.net
Currently the wiki wiki holds 224 web pages, and growing.
Quick has a small user community--we estimate it to be about 2,000. But we're hoping
to change that as we add additional capability,
especially in the P2P and B2B arena.
Bill
----- Original Message -----
From: "Sven Behrens" <[EMAIL PROTECTED]>
To: "dom4j-user" <[EMAIL PROTECTED]>
Sent: Friday, June 08, 2001 8:28 PM
Subject: [dom4j-user] XML as internal dataformat
> Hello,
>
> I am looking for the ideal internal format of some Metadata in an
> information catalog system.
>
> The (Meta)dataobjects result from a relational database (well known
> schema) and describe environmental information. There is not really any
> business logic in these data objects. In the past I just needed to
> render HTML from these data objects. (However, these data objects are
> quite complex and are build by many dependent SQL queries. So during
> construction I need access to some attributes.)
>
> Now I need
> 1) to render XML from these data objects and
> 2) to render the exact same HTML as before from external XML provided by
> external sources
>
> So for me it seems that I can benefit from an internal XML format
> (considering that I am not really happy with the actual internal data
> format consisting of some kind of entity (no EJB) with atomic- and
> self-made-java.util.Vector-based collection attributes.
>
> In the near future we possibly provide a data maintenance tool, too.
>
> One issue is, that due to distributed access (RMI) to many sources, I
> need a transport efficient format. (memory and speed is also an issue,
> of course)
>
> My questions:
>
> As far as I know, dom4j currently does not support serialization at all.
> When will this change and will the serialized format be tuned for
> efficiency? (I tested JDOM beta 6 and got about twice the volume I had
> from the already big XML-source...)
> Or would you recommend to create an XML-file and use this (e.g.
> compressed) for communication?
>
> Is this use case a typical one for the use of an lightweight XML-API?
>
> Do you think, Java-XML-Java Mapper tools (like Jato or Castor) would be
> more appropriate in this use case?
>
> Thanks in advance,
> Sven Behrens.
>
> _______________________________________________
> dom4j-user mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/dom4j-user
>
_______________________________________________
dom4j-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dom4j-user
