Re: [RT] Flow/Sitemap Integration

[Stefano Mazzocchi]

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

Another need is internationalized URI spaces: say you want 'www.mail.com/webmail' for english and 'www.posta.it/posta' for italian, and so on, but don't want to rewrite your flowscript method names.

Ahh, now there's a real use case...

Yep.

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

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.

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

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

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

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 <[EMAIL PROTECTED]>
--------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]