cocoon-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Conal Tuohy" <>
Subject RE: FAQ and snippet, document() function
Date Thu, 11 Jul 2002 00:21:13 GMT
> -----Original Message-----
> From: Diana Shannon []

Hi Diana

> On Tuesday, July 9, 2002, at 06:04  PM, Conal Tuohy wrote:
> > Don't be too quick to deprecate document()!
> Did my draft suggest that? Are you saying that pointing out
> the problems
> associated with using the document() function in a Cocoon environment
> (e.g. caching)
> which may discourage use of the document() function "in effect"
> suggests "deprecation"?

No ... it's the bit where you said it breaks SoC. That's the statement I
take issue with - I do think it is excessively deprecatory. It sounds like
you're telling people never to use document() in Cocoon.

Whereas I think that, in some instances, an XSLT (with document()) is
actually a better choice than the alternatives, and I think the Q&A should
make that clear.

Perhaps we could say:

Q. What's "wrong" with use of the document() function in Cocoon?

A. There's nothing wrong - so long as you maintain a proper Separation of
Concerns. But in most cases, there are simpler alternative techniques, so
document() should only be used when it is the best tool for the job.

These other techniques encourage (enforce?) SoC, because the aggregation
takes place as a distinct step in a pipeline. If you use XSLT to aggregate
content, you must take care to maintain SoC yourself. To do this, create an
XSLT which performs only the aggregation. Don't be tempted to transform the
aggregated data into a final result at the same time- use a separate XSLT
for this, and chain them together in a pipeline.

I'll see if I can put together a simple example of using document() and post
it to the list. In general, though, I think the compelling case is where you
need to aggregate lots of documents recursively. i.e.

doc A refers to doc B, doc B refers to doc C, doc C refers to D, etc.

You can run an XSLT transform on A which will aggregate A, B, C, and D (etc)
into a single doc. This is simple and efficient in XSLT. But to do the same
thing with XInclude, for instance, would require recursive calls into the
sitemap (potentially hundreds of such calls, depending on the number of
docs), possibly even caching each partial aggregate as the recursion
progresses. Ouch!

These are the heuristics I use (in order of decreasing preference):

1) Where the number of source documents is a constant, and the sources don't
themselves link to each other, then you should impose aggregation on them
"from outside" with map:aggregate. In this case the aggregation is specified
entirely in the sitemap - it's all nice and clear. But this isn't always
possible because sometimes you don't even know how many docs you are

2) Where the number of input sources is variable, and consists of links in a
document (or constant set of documents), you can transform those links to
<xi:include> elements, and then perform aggregation with XInclude.

3) Where the number of input sources is variable, consisting of links in an
entire "grove" of documents, then perform the aggregation with a custom XSLT



View raw message