Re: [RT] Flow/Sitemap Integration

[Stefano Mazzocchi]

Hunsberger, Peter wrote:

So I find the notion of "flow uri's" living side by side with "sitemap-pipline uri's" inside pipeline sections a little awkward. There seems to be some muddling of concerns here.

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.

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.

Infact, although flow function are defined within
"pipeline sections", they ignore them.


<map:pipeline type="has_no_ effect_on_flow_uri">
 <map:match pattern="loginFlowUri/">
   <map:call flow="login"/>
 </map:match>
</map:pipeline>

Now, discussions aside, *this* is a valid point and shows some 'hackiness' in the current semantics.

I totally agree with you.

This also suggests that you could abstract the pipeline type into some extra
level of flow control. For example consider:

<map:pipeline type="expert">
<map:match pattern="dashboard/">
...
</map:match>
</map:pipeline>
<map:pipeline type="intermediate">
<map:match pattern="dashboard/">
...
</map:match>
</map:pipeline>
<map:pipeline type="beginner">
<map:match pattern="dashboard/">
...
</map:match>
</map:pipeline>

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?

You are hardcoding pattern matching capabilities in your pipeline and this is not very nice, IMHO.

I'm sure there other ways to do the same thing
and this seems dangerous to me; this use case is wrong or at best weak, but
perhaps there would be other real pipeline types that you might want to
select from in this manner?

I really don't see any.

The pipeline "type" decides *how* the pipeline works internally, but it doesn't influence the way the components work or the system matches resources.

So, one thing could be to have

<map:pipeline type="stateless">
<map:match pattern="blah">
<map:call function="whatever"/>
</map:match>
</map:pipeline>

where no continuation is ever kept

and

<map:pipeline type="statefull>
<map:match pattern="blah">
<map:call function="whatever"/>
</map:match>
</map:pipeline>

where continuations are created and kept.

This seems to fragment concerns since it should be a flowscript's concern to know how to save state and not a sitemap's one.

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.

Implementation details aside, IMO, it would much cleaner if we could define a flow-uri mapping (a flowmap) and keep it together with the flow defintion itself.

Heck, my original intention was to separate the sitemap into sitemap (for resource) and flowmap (for flow)... but we didn't have an implementation back then, it was everything up in the air.... now we do have something that works, maybe we should start discussing this again.

In a way, if you implement your XML spec to flow generator don't you get
this for free? Or, in other-words, couldn't an XML flow spec and a flowmap
be one and the same thing?  It seems to me that if you can specify flow
generation via a language external to the sitemap you don't really need a
flow map?  Yes, the issue of mapping names (or whatever) to URIs still
exists, but your flow controller is already capable of that if you really
need it...

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.

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.

--
Stefano Mazzocchi <[EMAIL PROTECTED]>
--------------------------------------------------------------------



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