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 Williams <mi...@o3.co.uk> on 2000/01/25 12:13:40 UTC
XSP (minus Cocoon plus SAX) success story
Hiya ... I'm new to the list, though I've been following Cocoon
developments on and off for the last year.
For the past month or so, I've been developing an processor to produce
web-pages from XML templates. My servlets handle requests, construct a Map
full of data to be merged into the output, and use templates to produce a
result-page. The template resolver walks a DOM tree, and use FESI
ECMAScript to resolve merge-data expressions. The output is a stream of
SAX events.
Then last week, I saw the XSP stuff in Cocoon-1.6, and the penny
dropped. Way cool! I've now written an XSL stylesheet that tranforms an
XSP page into a Java template; again, input is a Map of merge-data, and
output is SAX.
Build-time:
{XSP} -> XSL(xsp) -> {template source} -> compile -> {template class}
Run-time:
{data Map} -> template -> {SAX} -> formatter -> {HTML}
There's no Cocoon code here: our pages are highly dynamic, so caching them
is not really an option. We don't do any XSL transformation of the output
either ... it's all done before the XSP step, so that all the layout ends
up coded in Java as SAX events-calls.
Anyway, the result is blinding fast: about 10 times the performance of my
original template interpreter! Many, many thanks to Stefano, for
conceiving XSP, and Ricardo, for demonstrating how to implement it. I'd
love to contribute my code to Cocoon, if it's at all useful ... just let me
know where to send it.
--
cheers,
Mike Williams
Re: XSP (minus Cocoon plus SAX) success story
Posted by Niclas Hedhman <ni...@localbar.com>.
I am certainly interested... Sounds like what we where about to do, or very
similar, since Cocoon is not 100% suitable for us.
Could you possibly send it over?? I host it if you like...
Niclas
Mike Williams wrote:
> Hiya ... I'm new to the list, though I've been following Cocoon
> developments on and off for the last year.
>
> For the past month or so, I've been developing an processor to produce
> web-pages from XML templates. My servlets handle requests, construct a Map
> full of data to be merged into the output, and use templates to produce a
> result-page. The template resolver walks a DOM tree, and use FESI
> ECMAScript to resolve merge-data expressions. The output is a stream of
> SAX events.
>
> Then last week, I saw the XSP stuff in Cocoon-1.6, and the penny
> dropped. Way cool! I've now written an XSL stylesheet that tranforms an
> XSP page into a Java template; again, input is a Map of merge-data, and
> output is SAX.
>
> Build-time:
> {XSP} -> XSL(xsp) -> {template source} -> compile -> {template class}
>
> Run-time:
> {data Map} -> template -> {SAX} -> formatter -> {HTML}
>
> There's no Cocoon code here: our pages are highly dynamic, so caching them
> is not really an option. We don't do any XSL transformation of the output
> either ... it's all done before the XSP step, so that all the layout ends
> up coded in Java as SAX events-calls.
>
> Anyway, the result is blinding fast: about 10 times the performance of my
> original template interpreter! Many, many thanks to Stefano, for
> conceiving XSP, and Ricardo, for demonstrating how to implement it. I'd
> love to contribute my code to Cocoon, if it's at all useful ... just let me
> know where to send it.
>
> --
> cheers,
> Mike Williams
Re: XSP (minus Cocoon plus SAX) success story
Posted by Mike Williams <mi...@o3.co.uk>.
Mike> I'd have to HTML-quote stuff ... Existing XHTML Formatters already
Mike> do a nice job of this.
Stefano> Sure, there are also tools like ECS ...
Okay, but the SAX event-stream model is more scalable.
On my last project, I built and used an HTML-object library very similar to
ECS. You basically build up a tree representation of the page, and then ask
it to spit itself out. But it's a very memory-hungry approach, as you're
creating all those objects. Similar to creating a DOM, really.
In addition, the application ends up *seeming* slower (from a user point of
view), as no output is sent to the browser until you've finished building
the document-tree.
Stefano> Simply put: what you do could be done with carefully written JSP or with
Stefano> a special XML DTD translated into JSP.
Well, sort of. My use of XSP is unlike JSP, in that it produces
"executable XML templates", rather than servlets, so it's not web-specific.
It's actually quite general: I'm also using it to create "templates" that
generate XML for server-to-server data exchange, where there's no HTTP
involved.
I see it more as a XSLT replacement. That is, rather than
{input} --producer--> {Java data} --encode--> {XML} --XSLT--> {XHTML}
I'm doing
{XSP} --XSLT--> {template}
{input} --producer--> {Java data} --template--> {XHTML}
It's very un-XML, I guess, as there's never any XML representation of the
raw output data. As somebody said, it's primarily a performance detail,
but I still think it's a useful one.
Stefano> XSP were designed to fill the holes that you are avoiding
Stefano> yourself, so not much point to use them unless you like XSP
Stefano> syntax more [than JSP].
I like it a lot :-)
Stefano> Just wanted to point out that the 10-times peformance increase
Stefano> was not due to the XSP model, but to the more general compiled
Stefano> server pages model.
Yup ... sorry I didn't make that clear. Still, it took Ricardo's XSP
implementation to see how easy it could be to generate Java code from XML,
using XSLT.
And let's not limit it to server-pages ... your XSP concept is more useful
than that :-) That is, the compile-to-Java concept is also useful for
generating dynamic XML (see above), compiled XSLT stylesheets (ala Saxon),
etc,
--
Mike Williams
http://www.o3.co.uk
Re: XSP (minus Cocoon plus SAX) success story
Posted by Stefano Mazzocchi <st...@apache.org>.
Donald Ball wrote:
>
> On Thu, 27 Jan 2000, Stefano Mazzocchi wrote:
>
> > I find myself in the strange situation where XSP is something in between
> > JSP and E-XSLT....
> >
> > if you know calculus enough, when three continuous functions
> >
> > f(x) <= g(x) <= h(x) for every 'x'
> >
> > and
> >
> > lim f(x) = lim h(x)
> > x->inf x->inf
> >
> > what happens to g(x)?
> >
> > That's how I feel XSP right now: a little squeezed between two big guys
> > :)
>
> Yeah, well, lots of us don't necessarily trust the bug guys closed
> development processes. What's E-XSLT anyway?
EXSLT := XSLT with extentions, such as <xt:document> or <xalan:whatever>
or <sql:query>
XSLT can be extended to allow new magic tags to perform operation at
runtime. Or, as I proposed to match XSP functionality, to perform
generation of java code that will result in an XML producer doing the
same job without the XSLT execution overhead.
>From a user point of view
<sql:query>select * from clients</sql:query>
results in output extracted from a database. If this is done at
interpretation time (parsing + xslt transformation + extended tags
evalutation) or compilation time (direct production), the result should
be entirely the same.
Only speed will change. (well, if a database is hit, probably not that
much difference anyway, but you get my point)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Come to the first official Apache Software Foundation Conference!
------------------------- http://ApacheCon.Com ---------------------
Re: XSP (minus Cocoon plus SAX) success story
Posted by Stefano Mazzocchi <st...@apache.org>.
Ricardo Rocha wrote:
>
> Stefano Mazzocchi wrote:
> > I find myself in the strange situation where XSP is something in between
> > JSP and E-XSLT....
> > . . .
> > That's how I feel XSP right now: a little squeezed between two big guys
> > :)
>
> Hmmm, unfortunately I've been so _incredibly_ busy these
> days I haven't had the time it takes to write a well thought out
> post about this. Damn it!
No problem (Ricardo is leaving the US for visa problems... and hopefully
end up living in Italy near my house.... talking about Exoffice stealing
friends :)
> I'll try to present one of the main points now before all of
> us end up losing our religion:
>
> XSP Layer 1 is a *code-generation* vocabulary. E-XSLT is
> part of a transformation vocabulary.
>
> This is a critical distinction!
Totally!!!!!
> XSP Layer 1 is a code generation vocabulary aimed at
> producing DOM transformation code. As such, it can be
> used to generate server pages (as it does now) or to
> generate E-XSLT extension handlers.
>
> Being a DOM transformation language, XSLT provides
> means of dynamically building nodes. When you say:
>
> <xsl:element name="continuous-function">
>
> you're saying "insert an element called 'continuous-function'
> at the current result tree position"
>
> In XSP Layer 1 (being a code-generation, server page
> vocabulary) when you say:
>
> <xsp:element name="continuous-frunction">
>
> you're actually saying "insert executable code to create
> an element called 'continuous-function' at the current
> source program position".
>
> These 2 are _not_ the same! Dynamic node building tags
> in XSLT and XSP cannot be unified.
yes yes yes yes yes yes
> Let's assume we're using XSP's code generation facilities
> to generate *XSLT extension handlers.* (a perfectly
> legitimate usage, as XSP doesn't dictate the final "rendition"
> of the generated source program as a servlet, a Cocoon
> producer or, yes, an XSLT extension handler).
>
> Think carefully: what would we use in this case? <xsl:element>
> or <xsp:element>?
>
> Are you done thinking? You see? XSP Layer 1 defines its
> own namespace, so it comes naturally a beast like
> <xsp:element> rightfully exists.
Yes, while I agreed that XSP should not define any better model of
transformation/generation since EXSLT provides that, I don't have a clue
on _how_ the two "interpretation/compilation" modes of operation can
coexists.
Probably, an extended tag will have two logicsheets: one for
interpretation, one for compilation. Great would be the ability to use
one for both, but it's probably impossible even if they share the same
logic. Hmmm... or maybe not... hmmm...
> The 2 syntaxes DO NOT overlap in regard to dynamic
> node creation.
No, they don't and will never do.
> The fact that both <xsp:element> and <xsl:element> yield
> a comparable end result does not mean their semantics
> are the same.
Totally well put.
> There's much more to this. I just wanted to present one
> of the key facts. As long as we (wrongfully) look at XSP
> as a plain transformation language we'll end up perceiving
> it as redundant in regard to E-XSLT. As soon as we introduce
> the code-generation factor, our function becomes clearer.
That's the key issue: if EXSLT is used to "interpret" the extended tags
into generated "content", this is nothing new from the normal EXSLT
perspective. If EXSLT is used to "generate code that, if executed,
results in the same content that would have been generated after the
interpretation level" that's another story.
The distinction should be clear now and forever, but it's not a design
problem, rather an implementation problem. That was, again, my wrong
assumption.
On the other hand, Scott once said that XSP and EXSLT were not different
ideas converging, but rather XSP a subset of the EXSLT ideas.
He is right from a design perspective, he's not from an implementation
perspective.
That's why I'm happy :)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Come to the first official Apache Software Foundation Conference!
------------------------- http://ApacheCon.Com ---------------------
RE: XSP (minus Cocoon plus SAX) success story
Posted by Ricardo Rocha <ri...@apache.org>.
Stefano Mazzocchi wrote:
> I find myself in the strange situation where XSP is something in between
> JSP and E-XSLT....
> . . .
> That's how I feel XSP right now: a little squeezed between two big guys
> :)
Hmmm, unfortunately I've been so _incredibly_ busy these
days I haven't had the time it takes to write a well thought out
post about this. Damn it!
I'll try to present one of the main points now before all of
us end up losing our religion:
XSP Layer 1 is a *code-generation* vocabulary. E-XSLT is
part of a transformation vocabulary.
This is a critical distinction!
XSP Layer 1 is a code generation vocabulary aimed at
producing DOM transformation code. As such, it can be
used to generate server pages (as it does now) or to
generate E-XSLT extension handlers.
Being a DOM transformation language, XSLT provides
means of dynamically building nodes. When you say:
<xsl:element name="continuous-function">
you're saying "insert an element called 'continuous-function'
at the current result tree position"
In XSP Layer 1 (being a code-generation, server page
vocabulary) when you say:
<xsp:element name="continuous-frunction">
you're actually saying "insert executable code to create
an element called 'continuous-function' at the current
source program position".
These 2 are _not_ the same! Dynamic node building tags
in XSLT and XSP cannot be unified.
Let's assume we're using XSP's code generation facilities
to generate *XSLT extension handlers.* (a perfectly
legitimate usage, as XSP doesn't dictate the final "rendition"
of the generated source program as a servlet, a Cocoon
producer or, yes, an XSLT extension handler).
Think carefully: what would we use in this case? <xsl:element>
or <xsp:element>?
Are you done thinking? You see? XSP Layer 1 defines its
own namespace, so it comes naturally a beast like
<xsp:element> rightfully exists.
The 2 syntaxes DO NOT overlap in regard to dynamic
node creation.
The fact that both <xsp:element> and <xsl:element> yield
a comparable end result does not mean their semantics
are the same.
There's much more to this. I just wanted to present one
of the key facts. As long as we (wrongfully) look at XSP
as a plain transformation language we'll end up perceiving
it as redundant in regard to E-XSLT. As soon as we introduce
the code-generation factor, our function becomes clearer.
Ricardo
Re: XSP (minus Cocoon plus SAX) success story
Posted by Donald Ball <ba...@webslingerZ.com>.
On Thu, 27 Jan 2000, Stefano Mazzocchi wrote:
> I find myself in the strange situation where XSP is something in between
> JSP and E-XSLT....
>
> if you know calculus enough, when three continuous functions
>
> f(x) <= g(x) <= h(x) for every 'x'
>
> and
>
> lim f(x) = lim h(x)
> x->inf x->inf
>
> what happens to g(x)?
>
> That's how I feel XSP right now: a little squeezed between two big guys
> :)
Yeah, well, lots of us don't necessarily trust the bug guys closed
development processes. What's E-XSLT anyway?
- donald
Re: XSP (minus Cocoon plus SAX) success story
Posted by Stefano Mazzocchi <st...@apache.org>.
Mike Williams wrote:
>
> >>> On Wed, 26 Jan 2000 12:58:58 +0100,
> >>> "Stefano" == Stefano Mazzocchi <st...@apache.org> wrote:
>
> Stefano> Ehmmm, not to rain on the parade, but what's the point of doing
> Stefano> this?
>
> Well, for a start, it's better than what I was doing before :-)
"1 - 0" for you :)
> Stefano> You use XSP to compile your page into a java class. I presume this class
> Stefano> is not a cocoon producer, so it must be a servlet or a class called by a
> Stefano> servlet, right?
>
> Right. Called by a servlet, which passes in a Map of data.
Ok.
> Stefano> This class interprets some data and spits SAX events that get formatted
> Stefano> in HTML. No cache, no post processing, nothing.
>
> No caching, but I do perform some post-processing. Mainly to re-write
> URLs, at the moment.
Ok, this may change the picture, then.
> Stefano> Why do you care spitting SAX events if nobody is processing them rather
> Stefano> than the formatter? just output HTML and you're done.
>
> Could do, but then I'd have to HTML-quote stuff, and so on. Existing XHTML
> Formatters already do a nice job of this.
Sure, there are also tools like ECS that do a magnificent job on this
(java.apache.org/ECS/)
> Stefano> Ok, so, what have we got here? JSP with another syntax. A quick and
> Stefano> dirty way of doing the same thing without any Cocoon code
>
> Stefano> XSP -> (xslt) -> JSP -> tomcat -> HTML
>
> Hmm, that's an interesting idea that hadn't occurred to me.
>
> I'm not quite sure what I'd gain, though. Currently, the things I'm
> producing using XSP are page-templates, ie. just presentation. All my
> control logic is in servlets (with business-logic and data-access in EJB),
> the idea being that a given page-template can be re-used by a number of
> different servlets.
>
> JSP mixes the control and presentation code into one file, though I guess I
> could have my servlets dump stuff in the request-attributes, and use JSP
> just for presentation. But then the question remains, why is
>
> XSP -> (xslt) -> JSP -> (compile) -> Java -> (compile) -> class
>
> any better than
>
> XSP -> (xslt) -> Java -> (compile) -> class
>
I thank you for this :) since you think that XSP will live long and
prosper, but others believe that JSP has a much longer life...
expecially now that both XSP and JSP are converging under the wings of
E-XSLT
>
> Stefano> NOTE: I base this elaboration on your message, so I might well miss a
> Stefano> very significant point, please tell me if it is so.
>
> Er, I'll let you be the judge of that.
Simply put: what you do could be done with carefully written JSP or with
a special XML DTD translated into JSP.
XSP were designed to fill the holes that you are avoiding yourself, so
not much point to use them unless you like XSP syntax more.
And if this is the case... I'm happy because I think JSP syntax sucks
too :)
Just wanted to point out that the 10-times peformance increase was not
due to the XSP model, but to the more general compiled server pages
model. Little difference, I agree, but it's easy to blind people with
such figures.
I find myself in the strange situation where XSP is something in between
JSP and E-XSLT....
if you know calculus enough, when three continuous functions
f(x) <= g(x) <= h(x) for every 'x'
and
lim f(x) = lim h(x)
x->inf x->inf
what happens to g(x)?
That's how I feel XSP right now: a little squeezed between two big guys
:)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Come to the first official Apache Software Foundation Conference!
------------------------- http://ApacheCon.Com ---------------------
Re: XSP (minus Cocoon plus SAX) success story
Posted by Mike Williams <mi...@o3.co.uk>.
>>> On Wed, 26 Jan 2000 12:58:58 +0100,
>>> "Stefano" == Stefano Mazzocchi <st...@apache.org> wrote:
Stefano> Ehmmm, not to rain on the parade, but what's the point of doing
Stefano> this?
Well, for a start, it's better than what I was doing before :-)
Stefano> You use XSP to compile your page into a java class. I presume this class
Stefano> is not a cocoon producer, so it must be a servlet or a class called by a
Stefano> servlet, right?
Right. Called by a servlet, which passes in a Map of data.
Stefano> This class interprets some data and spits SAX events that get formatted
Stefano> in HTML. No cache, no post processing, nothing.
No caching, but I do perform some post-processing. Mainly to re-write
URLs, at the moment.
Stefano> Why do you care spitting SAX events if nobody is processing them rather
Stefano> than the formatter? just output HTML and you're done.
Could do, but then I'd have to HTML-quote stuff, and so on. Existing XHTML
Formatters already do a nice job of this.
Stefano> Ok, so, what have we got here? JSP with another syntax. A quick and
Stefano> dirty way of doing the same thing without any Cocoon code
Stefano> XSP -> (xslt) -> JSP -> tomcat -> HTML
Hmm, that's an interesting idea that hadn't occurred to me.
I'm not quite sure what I'd gain, though. Currently, the things I'm
producing using XSP are page-templates, ie. just presentation. All my
control logic is in servlets (with business-logic and data-access in EJB),
the idea being that a given page-template can be re-used by a number of
different servlets.
JSP mixes the control and presentation code into one file, though I guess I
could have my servlets dump stuff in the request-attributes, and use JSP
just for presentation. But then the question remains, why is
XSP -> (xslt) -> JSP -> (compile) -> Java -> (compile) -> class
any better than
XSP -> (xslt) -> Java -> (compile) -> class
??
Stefano> NOTE: I base this elaboration on your message, so I might well miss a
Stefano> very significant point, please tell me if it is so.
Er, I'll let you be the judge of that.
--
Mike Williams
http://www.o3.co.uk
Re: XSP (minus Cocoon plus SAX) success story
Posted by Stefano Mazzocchi <st...@apache.org>.
Ben Laurie wrote:
>
> Mike Williams wrote:
> >
> > Hiya ... I'm new to the list, though I've been following Cocoon
> > developments on and off for the last year.
> >
> > For the past month or so, I've been developing an processor to produce
> > web-pages from XML templates. My servlets handle requests, construct a Map
> > full of data to be merged into the output, and use templates to produce a
> > result-page. The template resolver walks a DOM tree, and use FESI
> > ECMAScript to resolve merge-data expressions. The output is a stream of
> > SAX events.
> >
> > Then last week, I saw the XSP stuff in Cocoon-1.6, and the penny
> > dropped. Way cool! I've now written an XSL stylesheet that tranforms an
> > XSP page into a Java template; again, input is a Map of merge-data, and
> > output is SAX.
> >
> > Build-time:
> > {XSP} -> XSL(xsp) -> {template source} -> compile -> {template class}
> >
> > Run-time:
> > {data Map} -> template -> {SAX} -> formatter -> {HTML}
> >
> > There's no Cocoon code here: our pages are highly dynamic, so caching them
> > is not really an option. We don't do any XSL transformation of the output
> > either ... it's all done before the XSP step, so that all the layout ends
> > up coded in Java as SAX events-calls.
> >
> > Anyway, the result is blinding fast: about 10 times the performance of my
> > original template interpreter! Many, many thanks to Stefano, for
> > conceiving XSP, and Ricardo, for demonstrating how to implement it. I'd
> > love to contribute my code to Cocoon, if it's at all useful ... just let me
> > know where to send it.
>
> Sounds very interesting, but if it doesn't use Cocoon, presumably it
> belongs under some other part of the XML tree? I dunno, perhaps Cocoon
> should spread to encompass it?
Ehmmm, not to rain on the parade, but what's the point of doing this?
I mean, let's take a look at what you're doing:
> > Build-time:
> > {XSP} -> XSL(xsp) -> {template source} -> compile -> {template class}
You use XSP to compile your page into a java class. I presume this class
is not a cocoon producer, so it must be a servlet or a class called by a
servlet, right? Ok, let's move on...
> > Run-time:
> > {data Map} -> template -> {SAX} -> formatter -> {HTML}
This class interprets some data and spits SAX events that get formatted
in HTML. No cache, no post processing, nothing.
So, a quick and fast optimization would be
Run-time:
{data Map} -> template -> {HTML}
Why do you care spitting SAX events if nobody is processing them rather
than the formatter? just output HTML and you're done.
Ok, so, what have we got here? JSP with another syntax. A quick and
dirty way of doing the same thing without any Cocoon code
XSP -> (xslt) -> JSP -> tomcat -> HTML
if you like XSP syntax better, or simply
JSP -> tomcat -> HTML
if you care about compiled server pages only.
NOTE: I base this elaboration on your message, so I might well miss a
very significant point, please tell me if it is so.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Come to the first official Apache Software Foundation Conference!
------------------------- http://ApacheCon.Com ---------------------
Re: XSP (minus Cocoon plus SAX) success story
Posted by Ben Laurie <be...@algroup.co.uk>.
Mike Williams wrote:
>
> Hiya ... I'm new to the list, though I've been following Cocoon
> developments on and off for the last year.
>
> For the past month or so, I've been developing an processor to produce
> web-pages from XML templates. My servlets handle requests, construct a Map
> full of data to be merged into the output, and use templates to produce a
> result-page. The template resolver walks a DOM tree, and use FESI
> ECMAScript to resolve merge-data expressions. The output is a stream of
> SAX events.
>
> Then last week, I saw the XSP stuff in Cocoon-1.6, and the penny
> dropped. Way cool! I've now written an XSL stylesheet that tranforms an
> XSP page into a Java template; again, input is a Map of merge-data, and
> output is SAX.
>
> Build-time:
> {XSP} -> XSL(xsp) -> {template source} -> compile -> {template class}
>
> Run-time:
> {data Map} -> template -> {SAX} -> formatter -> {HTML}
>
> There's no Cocoon code here: our pages are highly dynamic, so caching them
> is not really an option. We don't do any XSL transformation of the output
> either ... it's all done before the XSP step, so that all the layout ends
> up coded in Java as SAX events-calls.
>
> Anyway, the result is blinding fast: about 10 times the performance of my
> original template interpreter! Many, many thanks to Stefano, for
> conceiving XSP, and Ricardo, for demonstrating how to implement it. I'd
> love to contribute my code to Cocoon, if it's at all useful ... just let me
> know where to send it.
Sounds very interesting, but if it doesn't use Cocoon, presumably it
belongs under some other part of the XML tree? I dunno, perhaps Cocoon
should spread to encompass it?
Cheers,
Ben,
--
SECURE HOSTING AT THE BUNKER! http://www.thebunker.net/hosting.htm
http://www.apache-ssl.org/ben.html
Y19100 no-prize winner!
http://www.ntk.net/index.cgi?back=2000/now0121.txt