cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject Re: [RT] Content Aggregation-another spin (long)
Date Wed, 24 Jan 2001 13:32:48 GMT
Robin Green wrote:
> I won't pretend to be following this discussion closely enough, but...
> But there's no need to introduce a reverse-order templating system. It's
> Flexibility Syndrome! Almost the same ease of use can be achieved with
> literal-result-element stylesheets (
> ) in the same order as normal (stylesheets after generators). This would be
> more consistent with normal Cocoon usage.
> Furthermore it has a lot more power if needed later, because you can use any
> kind of XSLT without changing your sitemap at all.

I originally though of something along those lines; however, there is no
way to get the results of _processed_ XSP pages.  It is not flexibility
syndrome, it is an extension of the XSLT process.  Currently there is no
consistent and controlled way to pass parameters from the Cocoon to the
XSLT engine (it works with Xalan but not with XT).  Furthermore, we need
the ability to specify the document to merge.  For example, the page I
presented earlier could be done with everything *except* the body.  I would
have to do something like this:

    <div class="header"><util:include-uri href="header.xml"/></div>
    <div class="nav"><util:include-uri href="nav.xml"/></div>
<!-- this can't be done: -->
    <div class="body"><util:include-uri href="{1}.xml"/></div>
<!-- =================== -->
    <div class="news"><util:include-uri href="news.xml"/></div>

In order to do this, you would have to bastardize the action proposal
and set a parameter, or you would have to get the URI and parse it
to get the body you wanted.

Can it be done now?  Yes.  But through much pain.

The aggregation system I proposed can work largely with the components we
already have.  Technically speaking, it could be simply a generator--that
way it works in a predefined manner.  Let me rephrase the idea as a Generator
as apposed to a separate Aggregation Component:

<map:match pattern="**.html">
    <map:generate type="file-aggregation" src="templates/site.xhtml">
      <part name="header" call="header.xhtml"/>
      <part name="nav" call="nav.xhtml"/>
      <part name="body" call="body/{1}.xhtml"/>
      <part name="news" call="news.xhtml"/>

<map:match pattern="header.xhtml">
    <map:generate src="templates/header.xhtml"/>
    <map:serialize type="xml"/>

<map:match pattern="nav.xhtml">
    <map:generate type="serverpages" src="docs/nav.xsp"/>
    <map:transform src="stylesheets/nav2html.xsl"/>
    <map:serialize type="xml"/>

<map:match pattern="body/**.xhtml">
    <map:generate src="docs/{1}.xml"/>
    <map:transform src="stylesheets/document2html.xsl"/>
    <map:serialize type="xml"/>

<map:match pattern="news.xhtml">
    <map:generate type="dir-aggregation" src="docs/news/today/*.xml">
      <root-element name="news"/>
    <map:transform src="stylesheets/news2html.xsl"/>
    <map:serialize type="xml"/>

Now we have a couple of issues, the recursiveness of the sitemap
(generators calling the sitemap to get results) and the visibility
of the parts of the document--no way of hiding the portions.
That might be resolvable with the use of resources.  That is assuming
that the end result will always be HTML, or easily merged in it's
final state.

View raw message