Sylvain Wallez wrote:
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...Which was the reason to call for a vote even if the discussion is not yet finalized :-)
I do know how lazy you people are :-) (oh, just because I'm even worse)
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_.
This is a very good point. I've thought about it as well.
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).
All true, action usefulness included.
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).
Again, true.
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.True, that is what I see replacing actions in the future, but that might not sound appealing in a programming environment where nobody knows ecmascript nor wants to learn it.
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.Yes, that makes sense.
Now, do you propose we change "pipelines/pipeline" with "processes/process"?
Besides the huge back compatibility effort of migration (not only code, but user knowledge), I don't find myself resonating with the concept of "process" since "pipeline" is... well... more fun :)
I mean, pipelines are something that cocoon was first to introduce in the xml server side world. Maybe it doesn't make sense from a purely core-up technological perspective, but it should does make sense from a user-reading-a-simple-sitemap-for-the-first-time point of view.
And, to be honest, I care about the second more than about the elegance of the first.
Do you see my point?
[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.
This is not only confusing, it's disturbing me a little.
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).yes, I see your point, even if, again, it's a technologically-driven perspective and will only confuse people before normal matching and super-selective matching. You know to know a lot about the internals to understand this.... can't we make it an internal transparent optimization of the sitemap interpreter? doesn't seem that hard.
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.
YES! That's it. That's what I couldn't see but perceived as wrong. This leads a pretty solid -1 to the use of <map:map>
Yes, I think I'm pretty much settled that we should not have two different semantics for pipelines and flows. I hear Sylvain about <pipeline> being really the problem but I can't think of a better term myself and process really sucks.
"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.
Yes, agreed.
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".True, but not evident at first. So I do understand Micheal concerns, altoghout I think that we'll end up duplicating 80% of the pipeline semantics just to force a design pattern that will emerge on the field anyway.
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).
But that will force us to call the new sitemap markup 2.0
If we rename "map:pipeline" to "map:process" and use the super-selector, here's a sample flow-driven sitemap :I like the underlying concepts, but I think that:
<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.
1) I don't like "process" enough and I don't think we have that much of an urge to change the semantics at that deep level.
2) the super-selector should be implicit (Berin proposed something along these lines a while ago)
Ah, and I have no objection for "cocoon:" calling scripts, and would love to call a pipeline with a different output stream !
Cool, but let's make it another vote. -- Stefano Mazzocchi <[EMAIL PROTECTED]> -------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
