cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <>
Subject RE: [RT] Flow/Sitemap Integration
Date Fri, 27 Dec 2002 21:51:11 GMT
Stefano Mazzocchi wrote:

> Hunsberger, Peter wrote:

<snip on stuff we agree about/>

>>>>Now, if the "type" was available in the flow, you could get different 
>>>>resources for the same flow.
>>>Well, how would Cocoon know how to match? Say I ask for '/dashboard' how 
>>>is the pipeline going to find out where to get the parameter in order to 
>>>match the user-level?
>> It would have to come from some higher level Cocoon component...
> well..
>> Essentially you'd invert the current pipeline flow: matchers/selectors
>> outside of pipeline types.
> but *why* braking everybody's sitemap when we have something else that 
> works perfectly with our current semantic?
>> I don't think it's currently worth spending any
>> energy discussing why such a thing would be a bad idea...
> 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.  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?...)

<snip on more stuff we agree on/>

>> Seems fair enough.  If that's the case then the recent issue about
>> internal resources seems relevant: shouldn't flow also match internal
>> resources?
> Yes, and AFAIK it does.

Someone had posted that they couldn't get it to work. Hadn't heard more

>>>Agreed. One way of solving this would be to have a way to generate a 
>>>flowscript out of a cocoon:/ pipeline. But we haven't decided if that is 
>>>a good thing or is FS.
>> Well I can certainly see how it might be nice to generate your language
>> dependant URI matching automagically...
> Well, it's damn easy to do it right now with a custom i18n-aware matcher:
>   <map:match type="i18n" src="mail"/>
> then this "i18n" matcher has a lookup table like this
>  <uri name="mail">
>    <alternate lang="EN">mail</alternate>
>    <alternate lang="IT">posta</alternate>
>    <alternate lang="FR">poste</alternate>
>    ...
>  </uri>
> There is no need to alter the sitemap semantics for this and no need to 
> have the flow involved.
> Damn, that's exactly the reason why I wanted pluggable matchers.

Are you saying this as a good thing or as a bad thing? Is there a problem
going forward?

> 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.

<snip on more agreement/>

>> Yes, I agree.  It seems that there is a real reason for indirect URI
>> from flow to pipeline, but no real reason to allow multiple types of
>> indirection.  As such, the addition of map:map isn't needed, you can
>> the same thing by adding a new attribute to the existing pipeline.  IE:
>>      <map:match pattern="login/" flow="login">
>> 		...
>>      </map:match>
>> But then the question of what to do with actions remains, (it seems too
>> early to deprecate them ;-)...
> Oh, I totally agree here.
>> The other new question is now; is the "flow" attribute in the above a
>> name (as per my original assumption), or in fact a pattern?
> 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...

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

View raw message