on Mon, 1 Sep 2003 17:43:14 +0200 Bertrand Delacretaz <[EMAIL PROTECTED]> wrote:
I think the current way of doing aggregation makes perfect sense if
you think of aggregating pipelines, not only generators.
AFAIK there are no plans to change this.
And I thing aggregator should be able to take anything that produces
SAX events - generators/resources/whatever, so people didn't have to use
pipeline-for-generator workaround.
It can. <map:part src="..."/> can take a remote URI, a local absolute URI, a local relative URI, and the output of another pipeline. What exactly is the limitation? For all intents and purposes from the user point of view, <map:part/> is a generator. If readers et al. (read: possible non-XML content) were allowed into <map:aggregate/>, Cocoon's XML processing contracts would be horribly broken. In addition, putting what amounts to a full pipeline in the aggregator has issues as well which I will explain below.
Having these resources in another pipeline has the added advantage of debugging. If it were specified in the aggregator, it would be much harder to isolate any problems. As a separate pipeline URI, unit tests (with finer-grained units) become simpler and more powerful. You can test the aggregated results and the standalone results independently. Having worked with Cocoon's sitemap for a while now, I cannot stress enough how often this comes up.
When finished testing, the standalone URI can be made a private, internal-use only URI. If you find that your sitemap is becoming unmaintainable because of these extra matchers etc., have you considered reviewing your sitemap to make sure your URI space is clean (eg. reduce or eliminate redundant matchers)? Also, with subsitemaps, it possible to split up a large and unweildy sitemap into smaller, logical subsitemaps for readability.
So what were the use cases for needing these added semantics to the aggregator that outweigh what was just mentioned?
- Miles Elam
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
