You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Mike Engelhart <me...@earthtrip.com> on 2000/05/25 16:27:57 UTC
XSP confusion
Hi all -
Ricardo's announcement that the XSP engine in Cocoon 2 is DOM based while
the rest of Cocoon 2 is SAX based has left me with some design questions. I
was planning on making all the code in my application use XML directly
(either DOM or SAX depending on what Cocoon 2 was going to use which I
assumed was SAX) rather than using XSP to generate the XML from existing
Java objects (e.g., iterating through a ResultSet or ArrayList, etc).
It seems from a performance standpoint, SAX is the way for me to go but does
this mean that I have to generate DOM objects every time I want to put an
XML element or fragment into an XSP dynamically?
Any thoughts??
Re: XSP confusion
Posted by Mike Engelhart <me...@earthtrip.com>.
on 5/25/00 10:01 AM, Ricardo Rocha at ricardo@apache.org wrote:
> XSP uses DOM _internally_ (i.e. for code generation purposes only), but
> the
> generated classes are SAX-based. Thus, whenever you need to put an XML
> element
> or fragment you'll use SAX, not DOM.
>
> Regards,
>
> Ricardo
OK - sorry about that. I thought it sounded it a little weird. That makes
sense now.
Mike
Re: XSP confusion
Posted by Ricardo Rocha <ri...@apache.org>.
Mike Engelhart wrote:
> Ricardo's announcement that the XSP engine in Cocoon 2 is DOM based while
> the rest of Cocoon 2 is SAX based has left me with some design questions. I
> was planning on making all the code in my application use XML directly
> (either DOM or SAX depending on what Cocoon 2 was going to use which I
> assumed was SAX) rather than using XSP to generate the XML from existing
> Java objects (e.g., iterating through a ResultSet or ArrayList, etc).
> It seems from a performance standpoint, SAX is the way for me to go but does
> this mean that I have to generate DOM objects every time I want to put an
> XML element or fragment into an XSP dynamically?
XSP uses DOM _internally_ (i.e. for code generation purposes only), but
the
generated classes are SAX-based. Thus, whenever you need to put an XML
element
or fragment you'll use SAX, not DOM.
Regards,
Ricardo
Re: XSP confusion
Posted by Stefano Mazzocchi <st...@apache.org>.
Ricardo Rocha wrote:
>
> Stefano Mazzocchi wrote:
> > Question:
> >
> > is there a performance difference between
> >
> > this.characters("ciao".getChars());
> >
> > and
> >
> > Chars ciao = {'c','i','a','o'};
> > ...
> > this.characters(ciao);
> >
> > (modulo java syntax errors, consider it pseudocode)
> >
> > I think so since the "ciao" string is translated into unicode and then
> > converted using the current local at runtime....
> >
> > Ricardo, since we declare the encoding on the XSP, shouldn't we
> > _preconvert_ all those strings into char arrays to avoid this at
> > runtime? I'm sure it could speed up simple println XSP pages by very
> > much.
>
> I'll add this to code-generation document preprocessing. Yes, sir!
>
> Generated code can be even space-optimized: If a given string happens to
> be a substring of another string, the latter can be "reused" by passing
> characters() the appropriate offset and length. This is probaly what
> SAX designers intended in the first place when they defined this
> otherwise
> "weird" method...
Hmmm, interesting.... didn't think of that one... a sort of compilation
compression... very nice indeed.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: XSP confusion
Posted by Ricardo Rocha <ri...@apache.org>.
Stefano Mazzocchi wrote:
> Question:
>
> is there a performance difference between
>
> this.characters("ciao".getChars());
>
> and
>
> Chars ciao = {'c','i','a','o'};
> ...
> this.characters(ciao);
>
> (modulo java syntax errors, consider it pseudocode)
>
> I think so since the "ciao" string is translated into unicode and then
> converted using the current local at runtime....
>
> Ricardo, since we declare the encoding on the XSP, shouldn't we
> _preconvert_ all those strings into char arrays to avoid this at
> runtime? I'm sure it could speed up simple println XSP pages by very
> much.
I'll add this to code-generation document preprocessing. Yes, sir!
Generated code can be even space-optimized: If a given string happens to
be a substring of another string, the latter can be "reused" by passing
characters() the appropriate offset and length. This is probaly what
SAX designers intended in the first place when they defined this
otherwise
"weird" method...
Re: XSP confusion
Posted by Stefano Mazzocchi <st...@apache.org>.
Giacomo Pati wrote:
> you're in trouble because in Cocoon 2 it will be something like
>
> xspAttr.clear();
> this.contentHandler.startElement("", "p", "p", xspAttr);
> this.characters("I'm a logicsheet-generated text!");
> this.contentHandler.endElement("", "p", "p");
Question:
is there a performance difference between
this.characters("ciao".getChars());
and
Chars ciao = {'c','i','a','o'};
...
this.characters(ciao);
(modulo java syntax errors, consider it pseudocode)
I think so since the "ciao" string is translated into unicode and then
converted using the current local at runtime....
Ricardo, since we declare the encoding on the XSP, shouldn't we
_preconvert_ all those strings into char arrays to avoid this at
runtime? I'm sure it could speed up simple println XSP pages by very
much.
Comments?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: XSP confusion
Posted by Ricardo Rocha <ri...@apache.org>.
Mike Engelhart wrote:
> My question is, why do I have to be in "trouble" :-)
> If I have classes that generate DOM elements and Node's (which I won't mind
> porting to SAX if need be) is there no way to easily append them to the XSP
> pages? This is where I'm confused about what direction to take. Is it
> prudent to start rewriting my methods that return DOM Element objects to
> return SAX objects? Any advice appreciated.
XSP for Cocoon2 will include an overloaded version of method xspExpr
that
accepts as argument a Node expression and automatically translates it
into
SAX events. Your DOM classes will continue to work.
In addition to this, a second markup language ("dom-xsp") will be
created
that simply wraps existing, DOM-based XSP1 pages and transforms their
generated
document into SAX events. This means additional overhead, yes, but
provides
a straight way to provide backwards-compatibility with the existing XSP1
codebase.
Ricardo
Re: XSP confusion
Posted by Giacomo Pati <Gi...@pwr.ch>.
Mike Engelhart wrote:
>
> My question is, why do I have to be in "trouble" :-)
> If I have classes that generate DOM elements and Node's (which I won't mind
> porting to SAX if need be) is there no way to easily append them to the XSP
> pages? This is where I'm confused about what direction to take. Is it
> prudent to start rewriting my methods that return DOM Element objects to
> return SAX objects? Any advice appreciated.
I don't know if I understand your question. If you have classes
producing DOM fragment and you want to still use them in C2 you may use
the helper classes in the xml/util to transform them to SAX events
(DOMStreamer.java).
Giacomo
--
PWR GmbH, Organisation & Entwicklung Tel: +41 (0)1 856 2202
Giacomo Pati, CTO/CEO Fax: +41 (0)1 856 2201
Hintereichenstrasse 7 Mailto:Giacomo.Pati@pwr.ch
CH-8166 Niederweningen Web: http://www.pwr.ch
Re: XSP confusion
Posted by Mike Engelhart <me...@earthtrip.com>.
on 5/25/00 3:35 PM, Giacomo Pati at Giacomo.Pati@pwr.ch wrote:
> I understand what Ricardo was saying is that the process of generating
> the java code from a XSP page is done using DOM. The compiled java class
> is in fact a generator which emits SAX events. As long as you use "pure"
> XSP you don't have to worry if it's DOM or SAX.
>
> If you use XSP internal stuff like:
>
> xspCurrentNode.appendChild(document.importNode(domElement, true));
>
> you're in trouble because in Cocoon 2 it will be something like
>
> xspAttr.clear();
> this.contentHandler.startElement("", "p", "p", xspAttr);
> this.characters("I'm a logicsheet-generated text!");
> this.contentHandler.endElement("", "p", "p");
>
> Giacomo
Thanks.
My question is, why do I have to be in "trouble" :-)
If I have classes that generate DOM elements and Node's (which I won't mind
porting to SAX if need be) is there no way to easily append them to the XSP
pages? This is where I'm confused about what direction to take. Is it
prudent to start rewriting my methods that return DOM Element objects to
return SAX objects? Any advice appreciated.
Mike
Re: XSP confusion
Posted by Giacomo Pati <Gi...@pwr.ch>.
Mike Engelhart wrote:
>
> Hi all -
>
> Ricardo's announcement that the XSP engine in Cocoon 2 is DOM based while
> the rest of Cocoon 2 is SAX based has left me with some design questions. I
> was planning on making all the code in my application use XML directly
> (either DOM or SAX depending on what Cocoon 2 was going to use which I
> assumed was SAX) rather than using XSP to generate the XML from existing
> Java objects (e.g., iterating through a ResultSet or ArrayList, etc).
> It seems from a performance standpoint, SAX is the way for me to go but does
> this mean that I have to generate DOM objects every time I want to put an
> XML element or fragment into an XSP dynamically?
I understand what Ricardo was saying is that the process of generating
the java code from a XSP page is done using DOM. The compiled java class
is in fact a generator which emits SAX events. As long as you use "pure"
XSP you don't have to worry if it's DOM or SAX.
If you use XSP internal stuff like:
xspCurrentNode.appendChild(document.importNode(domElement, true));
you're in trouble because in Cocoon 2 it will be something like
xspAttr.clear();
this.contentHandler.startElement("", "p", "p", xspAttr);
this.characters("I'm a logicsheet-generated text!");
this.contentHandler.endElement("", "p", "p");
Giacomo
--
PWR GmbH, Organisation & Entwicklung Tel: +41 (0)1 856 2202
Giacomo Pati, CTO/CEO Fax: +41 (0)1 856 2201
Hintereichenstrasse 7 Mailto:Giacomo.Pati@pwr.ch
CH-8166 Niederweningen Web: http://www.pwr.ch