cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: Allowed Sitemap Constructs
Date Sun, 06 Jan 2002 17:36:42 GMT
Stefano Mazzocchi wrote:

>Vadim Gritsenko wrote:
>>you have product catalog sub-sitemap:
>> <!-- high precedence URL patterns -->
>> <map:match>...</map:match>
>> <!-- process request parameters productId=xxx&addToComparison=yes -->
>> <map:act type="add-to-comparison"/>
>> <map:act type="product-selection">
>>   <map:generate/>
>>   <map:serialize/>
>> </map:act>
>> <!-- low precedence URL patterns -->
>> <map:match>...</map:match>
>>Example might be not perfect, but it gives an idea...
>Yeah, gives me the idea that the whole concept is screwed and can
>potentially be very harmful in the future!
>>>From the above fragment, the low precedence URL patterns are
>I have the perception that allowing actions (that are *always* executed)
>to happen side by side to matchers (which are not always executed) can
>lead to potentially dangerous results, like your example above!
>if a cocoon developer can make such a mistake, imagine what a cocoon
>newbie can do!

I think a few simple rules, even if they potentially open the door to 
dummy constructs, are better than a bigger set of complicated rules that 
try to allow only good constructs. KISS : keep it simple & stupid !

Carsten's description of sitemap behaviour is simple and almost complete 
(aggregation and error-handlers are missing). With these rules, even a 
newbie can understand why a post-match action isn't executed if there 
was a match.

The only problematic rule in this description - which originated this 
discussion - is that only matchers are allowed as top-level pipeline 
elements. I'd like to recall that this was only a bad side-effect of the 
patch overcoming the 64kbyte limit for large sitemaps. Before this 
patch, any element was allowed as top-level element. Had this patch 
taken care of that, this discussion would never have happened.

Introducing complicated rules has IMHO more drawbacks than benefits :
- they allow only what we subjectively define as "good constructs"
- it's hard for everybody to agree with these rules : see the number of 
messages in this thread :)
- they're hard to document clearly and thus hard to understand by newbies
- their implementation can be bug-prone

So what about simply removing the limitation on top-level elements, and 
add Carsten's description (with the few missing rules) to the docs ?


To unsubscribe, e-mail:
For additional commands, email:

View raw message