cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject XSP, taglibs and separation [was Re: Different Processors]
Date Thu, 16 Dec 1999 02:51:50 GMT
Steve Muench wrote:
> 
> |  <page xmlns="page.dtd"
> |        xmlns:util="apache.org/cocoon/utils"
> |        xmlns:xturbine="apache.org/turbine"
> |        xmlns:xqul="apache.org/cocoon/sql-processor">
> |
> |   <title>Hello, you've requested me <utils:count/> times.</title>
> |
> |   <p>
> |    Your shopping cart is currently: <xturbine:shopping-cart/>
> |   </p>
> |
> |   <p>
> |    Your data is: <xsql:query>select * from Data</xsql:query>
> |   </p>
> |  </page>
> 
> Stefano,
> 
> this is a great idea. You'll see that the next
> release of the Oracle XSQL Servlet has adopted a
> similar, namespace-based approach. It's the only
> way to keep things nice and straight.
> 
> My only general observations is that a page that
> looks like:
> 
>   <page xmlns="page.dtd"
>         xmlns:util="apache.org/cocoon/utils"
>         xmlns:xturbine="apache.org/turbine"
>         xmlns:xqul="apache.org/cocoon/sql-processor">
> 
>    <title>Hello, you've requested me <utils:count/> times.</title>
> 
>    <p>
>     Your shopping cart is currently: <xturbine:shopping-cart/>
>    </p>
> 
>    <p>
>     Your data is: <xsql:query>select * from Data</xsql:query>
>    </p>
>   </page>
> 
> Looks awfully similar to me to a single-template
> XSLT Stylesheet where your namespaces are
> referring to XSLT extension elements. The XSLT
> Stylesheet that would accomplish the exact same
> task is literally:
> 
>   <page xmlns="page.dtd" xsl:version="1.0"
>         xmlns:util="apache.org/cocoon/utils"
>         xmlns:xturbine="apache.org/turbine"
>         xmlns:xsql="apache.org/cocoon/sql-processor"
>         xsl:extension-element-prefixes="util xturbine xsql"
>         xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
> 
>    <title>Hello, you've requested me <utils:count/> times.</title>
> 
>    <p>
>     Your shopping cart is currently: <xturbine:shopping-cart/>
>    </p>
> 
>    <p>
>     Your data is: <xsql:query>select * from Data</xsql:query>
>    </p>
>   </page>
> 
> This is a legal, XSLT 1.0 REC-compliant stylesheet.
> No need for the <xsl:stylesheet> at the top. No need
> for the <xsl:template> when you're using XSLT with
> this simple, single-template stylesheet.
> 
> It's exactly the same as the document above,
> but with:
> 
>  - An added xsl namespace declaration
>  - An xsl:version="1.0" attribute
>  - An xsl:extension-element-prefixes attribute
> 
> It's resulting "datapage" could obviously be be transformed
> using another XSLT stylesheet (which would be full of <xsl:xxx>
> elements, rather than all extension elements!) to style
> the look of the "datapage" for presentation.

Yes, that's the key!!!!

This would allow us (Ricardo listen up!) to remove the taglib idea from
XSP Layer 1 alltogether and make my purist soul happy again :)
 
> This was what I have referred to on occasion
> in random email exchanges with you as
> the idea to "use an XSLT stylesheet *as* the page".
> At the time, you told me a lot of reasons why you
> thought it was not a great idea, but you seem to
> be converging on it from another vector... :-)

This is originally Ricardo's idea, I'm just copying it over.

There are lots of issues around here and I would like to clarify them a
little:

(Greg, please, read this carefully)

1) there's logic (pure code) and there's content (pure data).
Unfortunately the two are always mixed somewhere since code generates
data.

2) logic is defined in a programming language (pick one you like), data
in a structured meta-syntax (we'll suppose XML from now on)

3) the management efforts are reduced if strong contracts are developed
and context separated clearly so that each can evolve independently.
This is what we call "context separation" and it's the very "design
foundation" of the Cocoon project.

4) a meta-syntax alone is useless unless there is a way to transform one
syntax implementation into another. This is performed by XSLT on the XML
realm. Unlike DSSSL, XSLT is also expressed in XML, allowing an XSLT
document to transform itself.

5) Context separation is achieved _only_ thru transformations. Exactly
like stylesheets that are transformation instructions to apply style
information on content, logicsheets apply logic to pure content.

6) When using stylesheets, Content + Style = Layout, so you need a
layout language to come up with. This is the XSL:FO effort.

7) When using logicsheets, Content + Logic = server page, so you need an
XML-complete server page language. This is the XSP effort.

Under this light, it is clear that XSP don't offer content/logic
separation on purpose, exactly like FO don't provide content/style
separation. They are final formats.

FO is rendered to binary graphical formats or on screen.

XSP is "rendered" to binary machine code or interpreted in memory.

Exactly like you can't say: FO mixes everything so it sucks. You can't
say the same for XSP.

If you do, you haven't considered the whole thing from a global vision:
separation is performed thru XSLT, adding separation capabilities in
other places is "redundant" and leads to design flaws.

This is why I modestly think PIA (and Coldfusion and ASP) are lightyears
behind these ideas.

I've tried hard to make JSP work in place of XSP, but they don't for a
number of reasons.

XSP complete the technologies you need to do XML web publishing.
Everything else, it's just an application of the triad XSP/XSLT/XSL:FO
and stays one layer above.

Hope this clarifies my visions to all of you.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche



Mime
View raw message