cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
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
>unreachable!
>
>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 ?

Sylvain



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message