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...
> 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?
>>
>> 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. I don't think it's currently worth spending any
energy discussing why such a thing would be a bad idea...
> 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?
>> 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.
<snip on stateless vs. statefull types/>
> 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.
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?
>>>>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.
Well I can certainly see how it might be nice to generate your language
dependant URI matching automagically...
>>>>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 ;-)...
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?
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
