cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [vote] finilizing the pending votes on flow [was Re: [RT] Flow/Sitemap Integration]
Date Thu, 16 Jan 2003 23:03:17 GMT
Sorry to jump in lately, but the "vote" made me consider that thread as 
important and I finally looked at it. So here we go...

Semantic confusion induced by "map:pipeline"
First of all, I wonder if all this started because the sitemap top-level 
processing element is named _pipeline_.

There was a discussion recently about renaming map:pipelines because of 
a naming conflict with the new map:pipelines components. At that time, I 
proposed the word "process" to replace the current ("old" one) 
map:pipeline (see [1]).

I suggested "process" because the sitemap is the top-level authority in 
Cocoon that drives how a request is _processed_. And the fact that the 
sitemap implements the "Processor" interface shows that this is what was 
meant from the beginning.

Michael proposes to put the flow map out of map:pipeline because a flow 
doesn't build a pipeline. That's true, but even without flow, processing 
a request may not build a pipeline : consider redirects with 
"map:redirect" and actions (I know, you don't like actions, but you 
can't deny their usefulness).

The redirect can also be a "forward" (in the servlet meaning) if the 
redirect URI starts with "cocoon:". In that case, a pipeline is actually 
built, but indirectly (it definition is not explicitly visible at the 
redirect point in the sitemap).

I consider a call to a flow like a "computed" forward. Continuations are 
an added bonus, but a flow function finishes by a sendPage() which is 
actually a forward. So a flow handles application logic and indirectly 
builds a pipeline.

As a side note, I realize while writing this that I unconciously was 
aware of this when writing the TreeProcessor, as there's a subtle 
behavioural difference with the compiled sitemap engine : the compiled 
engine creates a pipeline instance right at the beginning of the 
sitemap, while the TreeProcessor defers this up to the _first 
encountered_ sitemap statement (generate, etc), which may _never come_ 
if there's a redirect. So the TreeProcessor is really a processor and 
not only a pipeline builder.


Overlap between "map:map" and "map:match"
The discussion outlined the overlap between "map:map" (compact notation 
for the flow) and "map:match". What priority should be given to one or 
the other ? Michael's opinion to give priority to the flow makes sense, 
but I share Stefano's wonders about "creative uses" of the flow ?

And I also find it very confusing to have the same component type used 
with two different statements.

Also, what about selectors ? Selectors are IMO largely under-used 
because their definition is too poor compared to matchers. I recently 
had some thoughts about this and will write a RT about "super-selectors" 
soon. Basically, the idea is to have selectors that are like a sequence 
of matchers of the same type. This allows for a more compact notation 
for successive matchers of the same type (which we have a lot in most 
sitemaps) and may lead to tremendous speed optimisations (hashmap lookup 
compared to sequential lookup).

For example, a "wildcard-uri" super-selector may allow the following 
notation :
<map:select type="wildcard-uri">
  <map:when test="login/">
    <map:call function="login"/>
  <map:when test="register*/">
    <map:call funcion="registerUser">
       <map:param name="foo" value="{1}"/>
  <map:when test="logout/">
    <map:call function="logout"/>

Also (but this may be a spec detail), I've not seen how variables set by 
matchers in "map:map" are made available to the flow function.

"map:mount", "map:handle-errors"
"map:mount" is used to call a subsitemap, but _what_ is called in that 
subsitemap ?
- a flow ? Then "map:mount" should be in the "map:flowmap".
- a pipeline ? Then it should be in "map:pipeline".

Same for "map:handle-errors" : how exceptions thrown by a flow function 
are to be handled ?

So we end up with a lot of statements being equally applicable to 
"map:flowmap" and "map:pipeline".

As a conclusion, my thoughts (and you may have guessed it) is that I 
don't see a real need for "map:flowmap". IMO, it introduces too much 
separation and new concepts that reuse existing components, all this 
leading to an increased learning effort.

We must also remember that a sitemap can have several "map:pipeline". 
This can be the structuration unit Michael is looking for, considering 
also that some of them (the ones producing the pages) can be marked as 

My opinion is that "map:pipeline" should be renamed to "map:process", 
eventually in a new version of the sitemap namespace (the TreeProcessor 
already has some provision for handling several processing languages).

If we rename "map:pipeline" to "map:process" and use the super-selector, 
here's a sample flow-driven sitemap :

  <!-- omitting views & resources -->
    <!-- flow processing -->
      <map:select type="wildcard-uri">
        <map:when test="login/">
          <map:call function="login"/>
        <map:when test="register*/">
          <map:call funcion="registerUser">
            <map:param name="foo" value="{1}"/>
        <map:when test="logout/">
          <map:call function="logout"/>

    <!-- page processing -->
    <map:process internal-only="true" pipeline="caching">
      <map:select type="wildcard-uri">
        <map:when test="login-page">
          <map:read src="login.html"/>

Note the "pipeline" attribute on the second "map:process" : it defines 
the pipeline implementation that will be used. The first "map:process" 
may have this attribute, but it will never be actually used since it 
doesn't contain pipeline statements.

Thanks for reading so far.

Ah, and I have no objection for "cocoon:" calling scripts, and would 
love to call a pipeline with a different output stream !


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

To unsubscribe, e-mail:
For additional commands, email:

View raw message