cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [RT] Flow/Sitemap Integration
Date Tue, 24 Dec 2002 23:02:34 GMT
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                               <stefano@apache.org>
--------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message