cocoon-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Conal Tuohy" <con...@paradise.net.nz>
Subject RE: FAQ and snippet, document() function
Date Wed, 24 Jul 2002 01:49:27 GMT
That looks really good to me. Go for it!

I had promised to post an example of recursive aggregation using document,
but I've had some problems which I'm still investigating. It looks to me
like the document() function is actually broken (in 2.0.2), for a start. I'm
going to investigate this further, but in the meantime, I won't be posting
this example. :-(

Con






> -----Original Message-----
> From: Diana Shannon [mailto:shannon@apache.org]
> Sent: Tuesday, 23 July 2002 11:35
> To: cocoon-docs@xml.apache.org
> Cc: conalt@paradise.net.nz
> Subject: Re: FAQ and snippet, document() function
>
>
> Here's what I hope to be a less "dogmatic" rewrite, thanks
> to input from Conal and Nicola Ken. I added the term "may" in
> the first sentence of the opening "A." paragraph. I also included
> advice for those who need to use of the document() function in
> Cocoon toward the end.
>
> |---------------- start ---------------------|
>
> Q. What's "wrong" with use of the document() function in Cocoon?
>
> A. Using the document() function for aggregation in Cocoon may break
> Separation of Concerns (SoC). That is, the designers of Cocoon
> view inclusion and transformation as different functions, best
> handled by separate Cocoon components. Treating them
> separately allows you to achieve performance gains and increases
> the resusability of your pipelines.
>
> Alternatives to the document() in the Cocoon environment include
> aggregation or the use of a multi-stage transformation using the
> XInclude Transformer. This involves transforming a list of documents
> (generated dynamically or statically) by adding xinclude
> elements which
> reference (via xpointer) specific document content, and then
> transforming
> again via the XInclude Transformer, to obtain the desired result.
>
> For an example of this, see:
>
> http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=102617106411067&w=2
>
> You'll achieve better performance if you aggregate content prior to
> transformation.
> This allows you to take full advantage of Cocoon's pipeline
> caching. In
> contrast,
> making dynamic document() calls inside an XSLT within a
> cached pipeline
> is problematic.
> At this time, Cocoon does not recognize changes in documents
> (called by
> the document() function)
> until the requested page expires from cache.
>
> Understand that the document() function was designed *before* xinclude
> with xpointer facilities existed. Had such capabilities been
> available,
> perhaps the document() function, which essentially mimics
> xinclude and
> xpointer,
> would have never been added to XSLT.
>
> Please note that if you must work with your XML files outside of the
> Cocoon environment, you may need to use the document() function
> in order to utilize the limited capabilities of other
> pipeline engines.
> This includes engines which are not xinclude-capable or which
> lack a predefined way to indicate document processing steps. If you
> are working with legacy code from non-pipelined engines, you
> may need to
> use
> the document() function as well, at least initially.
>
> If you do use the document() function in Cocoon, you can
> still observe
> SoC by
> having separate XSLT stylesheets perform inclusion and transformation
> functions.
> For example, you can put multiple XSLT transforms in a
> pipeline and have
> the
> first one perform inclusion and the second one perform
> transformation.
> However,
> be mindful of some unresolved caching issues in Cocoon related to the
> document() function.
> At this time, Cocoon is unable to check validity of content
> included via
> the document()
> function. In addition, the document() function implemented by
> Xalan is
> inefficient. See:
>    http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4257
> Until this bug is fixed, consider using Saxon instead for document()
> function-related parsing
> needs.
>
> For other aggregation/inclusion approaches, please stay tuned for
> XpathDirectoryGenerator (2.1 scratchpad),
> as well as Forrest's Libre (currently alpha in the Forrest cvs).
>
> |---------------- end ---------------------|
>
> If this is acceptable to everyone, I'll commit it in the XSLT FAQs.
>
> Thanks again to Nicola Ken and Conal.
>
> -- Diana
>
>


Mime
View raw message