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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
