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 Tue, 05 Sep 2000 15:04:23 GMT
Jens Lorenz wrote:
> 
> ----- 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 ?) ...

If you use a DOM instance _directly_ inside xsp:logic your stuff won't
be portable. Clear and simple.

Then up to you to use it or not, after you are aware of this.
 
> > 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 ?

This is correct.
 
> 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() ?

C2 will probably always call toSAX(), but we will provide an
AbstractXObject method that will wrap around your toDOM() method to
crawl the DOM object and throw SAX events.

At the end, porting would just mean changing from

 public myclass implements XObject

to 

 public myclass extends AbstractXObject

so my only suggestion is to make sure your bean doesn't extend directly
any other class (you can do it with your internal classes)

> Or is there another, better way ?

Better? I think this is just as simple as possible, but I'm open to
suggestions, as always.
 
> Are there examples ? (a grep 'toDOM' `find ~/cvs/cocoon2` didn't find
> anything)

This is not yet implemented in C2.

-- 
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