cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: SAX & DOM in tag libs (was: Re: Aha! got it! 64k limit)
Date Mon, 04 Sep 2000 10:56:27 GMT
Jens Lorenz wrote:
> 
> ----- Original Message -----
> From: Stefano Mazzocchi <stefano@apache.org>
> To: <cocoon-users@xml.apache.org>
> Sent: Saturday, September 02, 2000 12:28 AM
> Subject: Re: Aha! got it! 64k limit(was: new version of the sql
> logicsheetunder development)
> 
> > > 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.

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

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------



Mime
View raw message