Stefano Mazzocchi wrote: >
Hi again Stefano,
Peter Hunsberger here; I was watching for your reply to this since it seemed
to get specific about some of the issues we had discussed more generally a
couple of weeks ago.
<big snip/>
>>
>> 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...
>> 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. 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?
>> 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...
<snip/>
>>
>> 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 %-) ...
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
