On Mon, 23 Dec 2002, Stefano Mazzocchi wrote:
> I know almost everybody is idle for the holydays, but I want to reply to
> this before I forgot :)
Unfortunaltly my idle time is over and im now back in "freezing"
Germany. Hmmm...
>
> Michael Melhem wrote:
> > Hi,
> >
> > Ok, here is a little "rant" on flow/sitemap intergration :)
>
> First, let me tell you that I link your ranting style a lot :)
Please, dont encourage me! :P
>
> > 1. What Is A Cocoon Pipeline?
> >
> > There are at least two concepts of pipeline in cocoon.
> >
> > 1.1 The Sitemap Pipeline.
> >
> > A sitemap-pipeline basically acts as a "recipe" on how
> > to build a processing-pipeline. Sitemap-pipelines contain
> > information on the type of processing-pipeline to use, and the
> > set of processing components to be attached to them.
> >
> > Typically, the purpose of each "sitemap-pipeline uri"
> > is to build a specific processing-pipeline.
> >
> > (Of course entry points into pipelines/flows need not be URI's, one
> > can match on "whatever", but for purposes of this mail, I will
> > stick to URIs)
>
> And this might be a first strong hypthesis in your reasoning that must
> be taken into consideration.
>
> > 1.2 The Processing Pipeline
> >
> > There are several different types of Processing Pipelines,
> > noncaching, caching, caching-point, profiling, hintable etc..
> >
> > The processing pipeline is in effect the SAX-conducting "glue" or "pipe"
> > which holds the pipeline components together. Usually an XML stream
> > flows down this pipe and gets transformed by each of the
> > pipeline components until it gets serialized by the last
> > pipeline component - the serializer (no surprise here).
> >
> > 2. What is A Flow?
> >
> > A flow is controlled navigation through a set of
> > processing-pipelines.
>
> The above is slightly incorrect, I would say:
>
> - a pipeline is the way cocoon uses to produces resources (readers can
> be seen as 'condensed pipelines' for non-XML resources)
Yes, at more abstract level, a processing pipeline can be described as
a resource-producer.
>
> - a flow is controlled navigation thru a set of resources
>
> the difference is the level of indirection provided by the URI space
> that provides the contract between the two. This is important to be able
> to separate the flow from actual pipeline descriptions and keep concerns
> separate.
>
> > That is, the purpose of "flow uri" is _not_ to build a
> > processing-pipeline, but rather, to define a application specific
> > flow through a logical set of them.
>
> Again, the flow controls navigation between a logical set of
> 'resources', not pipelines. The fact that those resources are associated
> to pipelines is merely an implementation detail in this context.
Well the point here, no matter whether we use the word "pipeline" or
"resource", is that flows and resources/pipelines are fundimentally
different "beasts" and probably shouldnt be living in the same paddock.
>
> >
> > This means a "flow-uri" is not same as a "sitemap-pipeline uri".
> > Conceptually flow URIs are not part of pipelines at all, they are
> > extra-pipeline. They act on pipelines.
>
> I do see your point but still your terminology might be misleading...
> more comments below.
>
> > ---
> >
> > 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.
>
> > 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.
>
> > 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.
>
> > For example, one can define a flow for a sitemap like this:
> >
> > <map:flow language="JavaScript">
> > <map:script src="prefs.js"/>
> >
> > <map:flowmap>
> > <map:match pattern="kont/*">
> > <map:call continuation="{1}"/>
> > </map:match>
> >
> > <map:match pattern="login/">
> > <map:call function="login"/>
> > </map:match>
> >
> > <map:match pattern="register/">
> > <map:call function="registerUser"/>
> > </map:match>
> >
> > <map:match pattern="logout/">
> > <map:call function="logout"/>
> > </map:match>
> > </map:flowmap>
> > </map:flow>
> >
> > This way we actually define the "uber-contoller" for the sitemap
> > in one place leaving the pipeline section as follows:
> >
> > <map:pipelines>
> > <map:pipeline>
> > ...
> > <map:match pattern="body-examples/*/**.xml">
> > <map:generate src="examples/{1}/pages/{2}.xsp" type="sp"/>
> > <map:transform src="stylesheets/document2html.xsl"/>
> > <map:serialize type="xml"/>
> > </map:match>
> >
> > <map:match pattern="body-**.xml">
> > <map:generate src="docs/{1}.xml"/>
> > <map:transform src="context://.../document2html.xsl"/>
> > <map:serialize/>
> > </map:match>
> > </map:pipeline>
> > ...
> > </map:pipelines>
> >
> > This way (with most actions and flow logic moved into the flow),
> > sitemap-pipelines become just that, pipelines!
> >
> > Conceptually a client can either invoke pipelines via flow (indirectly),
> > or invoke a pipeline directly.
>
> Assuming you want to keep that semantics all in the sitemap (you don't
> specify so, but I would tend to see that)... we must define the order of
> matching preference between <flow> and <pipelines>
I would suggest flow have matching preference before the <pipelines>. If
a sitemap has a flowmap defined, then its likely that for the most part,
the sitemap recources are accessed via the flow and not directly.
>
> > ---
> >
> > 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.
Why would this force us to tie flow calls only to uri matchers? The
treeprocessor when processing the flowmap would lookup existing
matcher components. So all existing matcher "types" are available.
>
> 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?'
My initial thoughts are that we do not get rid of matchers at all, but
rather, we specify the matcher type we want to use inside the map tag.
The following is how one would match flow URIs with regexp:
<map:map matcher="regexp" uri="blah*" flow="blahFlow">
We only constrain the sitemap markup within the the <flowmap> tags
to enforce "best practice" (and to make the mapping syntax more
compact and readable). We do not require new flowmap matcher
componets etc.
Best Regards,
Michael Melhem
>
> I like your concepts, anyway, let's see what others have to say about this.
> --
> Stefano Mazzocchi <[EMAIL PROTECTED]>
> --------------------------------------------------------------------
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
