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 21:20:03 GMT
Hunsberger, Peter wrote:
> Stefano Mazzocchi wrote:
>>>>Oh boy, it's already hard enough to indicate what is a good URI, if we
>>>>start discussing what is a 'flow uri' compared to a 'resource uri' we 
>>>>get in trouble.
>>>This comes at the matching issue the opposite way that I did 
>>>initially: instead of assuming that it is a unique resource name the 
>>>assumption seems to be that there is always a level of re-direction.  
>>>We discussed whether there was a real need for this and although I 
>>>thought it was interesting the only use case I could find was to allow 
>>>systems external from Cocoon to also be controlled from the flow 
>>Another need is internationalized URI spaces: say you want 
>>'' for english and '' for italian, 
>>and so on, but don't want to rewrite your flowscript method names.
> Ahh, now there's a real use case...


>>Also, indirection is a good protection against intrusive injection of 
>>scripting since it wan't be enough to inject an harmful script, but you 
>>also need to modify the sitemap to redirect to the method.
> It seems unlikely it would help much: most often script injection exploits a
> faulty POST handler.  Having found such a beast, you can usually just round
> trip a bad form field.  However, I suspect you're really suggesting that it
> may help stop cross site scripting exploits and that seems more likely?

No, forget about it. I thought more about it and it doesn't really make 
sense what I said. Ingore.

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


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

>>You are hardcoding pattern matching capabilities in your pipeline and 
>>this is not very nice, IMHO.
> Well, no, it might not be hard coded pattern matching, (though my simple
> example was), each pipeline might still use generic pattern matching.  What
> I was getting at is that there may be flow "types" that are orthogonal to
> the URI space in some applications.  Being able to have some kind of generic
> flow type matching capability seems so far FS, but, if you're adding URI
> indirection it seems worth while to ask: are there different types of
> indirection?

This is a good question. I'll have to think about it more. Right now I 
can't think of anything that would help me answer it.

>>But my point is that pipeline 'type' should indicate *how* the pipeline 
>>operates for all the resources it receives. it's a URI-space agnostic 
>>setting and I'd like to keep it so.
> Seems fair enough.  If that's the case then the recent issue about matching
> internal resources seems relevant: shouldn't flow also match internal
> resources?

Yes, and AFAIK it does.

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

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.

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.

The only partial overlap is between matchers and selectors.... but for 
back compatibility we have to support both even if we find a way to get 
rid of one of them.

>>>>>If it is decided that best practice is to disallow actions and 
>>>>>components around flow calls:-
>>>>>     <map:match pattern="login/">
>>>>>       <!-- no sitemap routing/Acting components allowed -->
>>>>>       <map:call function="login"/>
>>>>>       <!-- no sitemap routing/Acting components allowed -->
>>>>>     </map:match>
>>>>>Then perhaps the flowmap can be further simplified by introducing a
>>>>>new sitemap element "map:map". This means we can rewrite the flowmap 
>>>>>section as follows:
>>>>>   <map:flowmap>
>>>>>     <map:map uri="login/"  flow="login">
>>>>>     <map:map uri="register/"  flow="registerUser">
>>>>>     <map:map uri="logout/" flow="logout">
>>>>>   </map:flowmap>
>>>>>This way we enforce best practice and keep routing control in the 
>>>>>flow and out of the sitemap.
>>>>Hmmm, this is an interesting concept but this doesn't only prevent the
>>>>use actions before calls (something which I'd deeply love to see 
>>>>enforced, but that's my personal view, of course, and you all know my 
>>>>stand against actions) it also *forces* the flow calls to be tied to URI 
>>>>I wonder, is this the case? by getting rid of matchers, we are also
>>>>getting rid of the ability to keep them pluggable... and first objection 
>>>>would be 'how do I match flow URI with regexp?'
>>>Here you have an opportunity for all kinds of over design...  You 
>>>could add "type" to the flowmap to allow my expert, intermediate, 
>>>beginner use case. You could also add "type" to the map:map to specify 
>>>the type of matcher (and get regexp or whatever back). Or you could 
>>>add a pseudo protocol support to the flow attribute and support 
>>>multiple simultaneous flow controllers (and maybe have expert, 
>>>intermediate, beginner flows as opposed to expert, intermediate, 
>>>beginner resources). The mind boggles %-) ...
>>But you would be reimplementing functionality that already exists for 
>>matchers. Let's try to reuse concepts and reduce as much overlap as 
> Yes, I agree.  It seems that there is a real reason for indirect URI mapping
> 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 achieve
> 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 unique
> 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.

Stefano Mazzocchi                               <>

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

View raw message