cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: Splitting xconf files step 2: the sitemap
Date Tue, 04 Jan 2005 12:25:05 GMT
Peter Hunsberger wrote:

>On Mon, 03 Jan 2005 15:55:23 +0100, Daniel Fagerstrom
><> wrote:

>>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
I didn't understod the difference between your generic generator and the 
file generator, both uses a cocoon source, checks if it is XMLizable and 
generate SAX from it, what am I missing?

>  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
Sure, if you don't want to use the sitemap at all, it shouldn't matter 
if it is declarative or not ;)

What I find most important ATM is to make simple things simple to achive 
in Cocoon. For me and my colleagues, Cocoon in most cases already is 
powerfull enough. But for many simple and common use cases there are 
rough edges that decreases productivity and makes the threshold for 
being able to start using Cocoon unnecesarily high IMO. So if your use 
case can illuminate some isue that can make Cocoon simpler to use for 
basic use cases I'm interested, but if it as extreme as you say, I'm not 
within your target audience for this.


Anyway, sometimes when I need to refactor or add functionallity to some 
of our Cocoon applications, where I or colleagues of mine have written 
endless sitemaps, I have felt that it would have been nice if the 
sitemap would have been more declarative so that I could have asked it 
basic things like geting a list of what URLs or URL pattern it handles. 
Also if I have an URL in a large webapp and it doesn't work as expected 
it can require quite some work to trace through all involved sitemaps to 
see what rule that actually is used.

Of course I understand that if I used a set of efficient conventions 
about how to structure my URL space and my sitemaps the problem would be 
much less. Problem is that I don't have found such a set of conventions 
yet. Of course I'm following some kind of principles, but I don't have 
anything that I'm completely happy with yet. Anyone having good design 
patterns for URL space structuring and sitemap structuring, that you 
want to share?

>  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
Should be possible.

> Then you'd also need a way for flow functions to communicate
>that same information since flow can behave as a matching component
Don't feel any itch to support perverse use cases ;)

>  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...
That would be a step forward.


View raw message