cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] Flow/Sitemap Integration
Date Fri, 27 Dec 2002 22:27:37 GMT
Hunsberger, Peter wrote:
> Stefano Mazzocchi wrote:
>>Then don't propose it.
> I don't think I will!  However, when doing architecture you always have to
> ask if inverting a control flow makes sense; sometimes abstractions suddenly
> become obvious or new use cases jump out.

Oh totally. That's why I take time replying to your messages even if 
they might sound too "devil's advocate"-ish to many here. ;-)

> If one was to do such a thing
> with the Cocoon sitemap obviously you'd have to allow the current semantics
> to continue to work so you'd introduce some complete new concept (what's the
> inversion of a pipeline?...)

Not only that. Everytime you add a new construct you are not adding just 
*one*, but you are adding all possible combinations of that construct 
with everything that was there already.

This is why I'm always *very* careful about adding new functionality.

>>Damn, that's exactly the reason why I wanted pluggable matchers.
> Are you saying this as a good thing or as a bad thing?

The sitemap components interfaces were designed so that concerns remain 
separate. From that point on, I'm happy with *anything* that comes out 
of that. That means: I'm happy about people experimenting new 
functionality by adding more components that fit the architecture.

I tend to me a little more nervous when people try to force the 
architecture to do stuff that it can already do but in other ways that 
break back-compatibility.

> Is there a problem going forward?

Not at all!

>>You can have the equivalent of mod_spelling as a matcher as well... or 
>>you could have that table stored into a database... it's up to your 
>>matching logic.
>>But matching is a special concern and I want to keep that separate from 
>>flow and other sitemap components.
> Sounds very good to me.


>>If that was a patter, that would mean that you'd be calling possibly 
>>more than one function in the flowscript at the same time and I would 
>>*NOT* like this.
> That makes sense (I was assuming first match wins, but I can't see a reason
> to support it).  In that case, you're back to my original assumption: unique
> names and you can hash map the whole works. 


> Of course I'll probably always
> wonder if there aren't multiple types of URI matching...

Totally, that's exactly the reason why the entire URI matching logic is 
pluggable and not built into the sitemap.

Stefano Mazzocchi                               <>

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

View raw message