cocoon-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: FAQ and snippet, document() function
Date Thu, 11 Jul 2002 06:35:22 GMT

Conal Tuohy wrote:
>>-----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
> aggregating.
> 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
> script.

Remember that using document(), you are effectively bypassing the Cocoon 
cache mechanism.

We will be able to give a TTL for the cache of single aggregation parts; 
  with XSLT it will not be possible, because out of our control.

What you need is an XSLT-like syntax for aggregation,
because you may need many documents and not only one?

Again, you should have them defined in the Generation stage, where you 
have created the include directives, not after.

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

View raw message