Re: [vote] finilizing the pending votes on flow [was Re: [RT] Flow/SitemapIntegration]

[Sylvain Wallez]

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.

[1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104221105317073&w=2

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>
<map:when test="register*/">
<map:call funcion="registerUser">
<map:param name="foo" value="{1}"/>
</map:when>
</map:when>
<map:when test="logout/">
<map:call function="logout"/>
</map:when>
</map:select>

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".

Conclusion
-----------
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 "internal-only".

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 :

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

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

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

--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]