cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Hunsberger <>
Subject Re: Splitting xconf files step 2: the sitemap
Date Mon, 03 Jan 2005 18:24:39 GMT
On Mon, 03 Jan 2005 15:55:23 +0100, Daniel Fagerstrom
<> wrote:

<snip>lot's of stuff on other topics from what follows:</snip>

> Part of the problem is that the sitemap is "non-declarative" in the
> sense that all matchers must be executed in order untill one matches
> before you know if a sitemap respond to a certain URL. While the
> BlockWiring mount is a little bit more declarative so that you can have
> a bidirectional mapping between the block protocol and "external" URLs.
> I think that it will confuse users to use both "declarative" and
> "procedural" mounts in the same application.
> Personally I think that I prefer mounting both components and sitemaps
> from blocks in the application sitemaps that use them. It however
> requires that we find a way to implement the link transformer in this
> context.
> Somewhat RT I believe that the pluggable matchers in the sitemap is FS
> and do more harm than good. I'm certain that there are edge cases where
> it is usefull to plug in special pupose matchers and selectors. But the
> disadvantage is that the sitemap not is declarative in its mapping
> between URI:s and pipelines and as a consequence it is not possible to
> ask the sitemap anything about its URI space.

This is an interesting point.  I wrote a couple of weeks ago about a
"generic" generator and I finished up a basic implementation over the
holidays.  This basically ends up turning the sitemap into a single
match "**" and everything is then looked up based on database mappings
to data sources internally to our application.  Our case is extreme
since everything (and I mean everything) is dynamic; we've reached the
point where having to code anything statically doesn't work.

Our next step will be to replace the static pattern of aggregated
generators within the match to a dynamically generated aggregation
lists.  At that point the Cocoon sitemap will be out of our
application loop: the generic match will call flow which will get the
list of datasources.  Flow will essentially do it's own aggregation
processPipelineTo to a Cocoon source and that source will be picked up
and sent on to the transformers.

That's lots more explanation than you need, but the essential point is
that, for us, having the Sitemap be declarative doesn't gain us
anything.  A year ago I wouldn't have dreamed of abusing Cocoon in
this way, but I can't see any nice way around it for what we need to

RT: writing this I wonder if there would be some new method(s) you
could add to pluggable matchers so that they would behave
declaratively?  Essentially, at a Cocoon internals level you'd need
some kind of semantics/grammar for a matcher to tell Cocoon how it was
matching. Then you'd also need a way for flow functions to communicate
that same information since flow can behave as a matching component
also.  What this would gain you would be way to, after the fact, get
Cocoon to generate the equivalent of the declarative map that you
could at least use for debugging and documentation purposes...

Peter Hunsberger

View raw message