cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jens Lorenz" <jens.lor...@interface-business.de>
Subject Re: SAX & DOM in tag libs (was: Re: Aha! got it! 64k limit)
Date Mon, 04 Sep 2000 14:45:26 GMT

----- Original Message -----
From: Stefano Mazzocchi <stefano@apache.org>
To: <cocoon-users@xml.apache.org>
Sent: Monday, September 04, 2000 12:56 PM
Subject: Re: SAX & DOM in tag libs (was: Re: Aha! got it! 64k limit)


> > > > Well. What about compiled tag libs ? (java class together with
> > stylesheet,
> > > > as the provided ones - C1)
> > > >
> > > > I've tried to find a way to avoid the DOM stuff, but I haven't found
one
> > ...
> > > > (and I'm now heavily depending on the DOM stuff in order to create
> > > > XML fragments)
> > > >
> > > > Is there an independent _and_ efficient way to create XML fragments
?
> > > >
> > > > I've tried building long strings with the XML text in it, but the
> > > > xspParser (used by util:include-expr) need's a looooong time to
parse
> > > > such an string ... (much too long)
> > >
> > > Can you elaborate more? If what we have today forces you to use DOM
> > > there is something wrong in the design and we should fix this in C1
ASAP
> > > before you guys have too much legacy stuff to port.
> > >
> > > Please, give us more info so that we can fix the problems (your code
> > > should be totally DOM agnostic and XSP should enforce this).
> >
> > Well. I'll try to ...
> >
> > So. Basically I render Java class contents into XML Code ... (The data
> > originates in a DB, but there are Beans between the DB and my tag lib
> > provided some simple document and content managment system)
> >
> > Let's say I 've a bean containing some items (other beans) and some
basic
> > properties ...
> >
> > class Bean {
> >   public int ClassId;
> >   public Bean[] getItems();
> > }
> >
> > and I want to have something like:
> >
> > <bean>
> >   <classid>1</classid>
> >   <items>
> >     <bean>
> >       <classid>2</classid>
> >     </bean>
> >     <bean>
> >       <classid>3</classid>
> >     </bean>
> >   </items>
> > </bean>
> >
> > on this structure I could use some XSLT in order to make in human
readable
> > ...
> >
> > The thing I do now is having an XSPBeanLibrary with many static
functions
> > providing the functionality and all the dynamic data is put into the
> > HttpSession of the Servlet-Container ...
> >
> > class XSPBeanLibrary {
> >   public static Element getBean(int ClassId);
> > }
> >
> > together with a logic sheet
> >
> > <xsl:template match="getBean">
> >   <xsp:expr>
> >     XSPBeanLibrary.getBean(Integer.parseInt(<xsl:value-of
select="ClassId">)
> >   </xsp:expr>
> > </xsl:template>
> >
> > Thus, <xsp:expr> in C2 had to convert all my DOM Element stuff (and also
> > Document to create the Elements and Nodes) to SAX. Though this is not
> > impossible (as there are already several DOM2SAX converters) it's
> > wastes more time and memory, than using SAX direct. (for example
> > via xsp:element and xsp:attribute)
> >
> > ... and my Beans may have many items and properties ... I'll use some
> > mechanism to select only certain, but for the application there will
> > be a tree of the beans to be displayed ... So I've to call getBean
> > recursively to create an XML tree which I've to insert into the
> > original XML tree (thus replacing <getBean>) ...
> >
> > And I also do not want to switch to clean-page model, since I've done
> > already too much with tag libs ... and they also give me the ability
> > to separate the xsp logic from bean logic ... (important to have more
> > than one person work on a tag library and having more than one class
> > with logic)
> >
> > So. The big question is: how to create XML fragments in the tag library
> > without depending on the DOM/SAX/whatever_there_will_be_in_some_years
> > stuff but also not wasting too much time and memory in converting ...
>
> Ok, your concern is serious and my answer is solid: implement XObject!
>
> This class provides you with two methods:
>
>   void toSAX(ContentHandler handler);
>
>   DocumentFragment toDOM();
>
> and in C2 we'll provide abstract classes that allow you to implement
> just one of the two (in your case toDOM() since your logic is DOM based)
> and let Cocoon generate the SAX events. Or implement the toSAX method
> directly and the toDOM method will be ignored.
>
> When XML-izing complex information XSP logic should not be used (like
> you are doing), there is no easy way around it.

I'm afraid I don't understand ... Do you mean, that I do not use XSP
logic (well, at least I use xsp:expr) and that's good or that I use
XSP logic and I should try another way ... (if, which ?) ...

> But returning XObjects to xsp:expr elements guarantees future
> compatibility with new document creation technology.

Well, I'm afraid I don't get the point in XObject ... It's an interface
in org.apache.cocoon.framework providing your two methods ...

Well assuming the model above, shall I extend class Bean and implement
XObject and implement the toDOM() method an returning these Objects
to <xsp:expr> statement ?

e.g.:

public class XBean extends Bean implements XObject {
  void toDOM(org.w3c.dom.Node node)
  {
    Node.appendChild(node.getOwnerDocument().createTextNode("foobar"));
  }

  void toSAX(org.xml.sax.DocumentHandler handler)
  {
    // do nothing ...
  }
}

Well, C1 will call always toDOM() and C2 will check for toDOM() method and
if present use it, otherwise use toSAX() ?
Or is there another, better way ?

Are there examples ? (a grep 'toDOM' `find ~/cvs/cocoon2` didn't find
anything)


Regards,

Jens

--

jens.lorenz@interface-business.de

interface-business GmbH                             \\|//
Tolkewitzer Strasse 49                              (o o)
01277 Dresden                               ~~~~oOOo~(_)~oOOo~~~~
Germany



Mime
View raw message