Stefano Mazzocchi wrote:
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)
You got me ;-) <snip what="mutual agreement"/>
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?
Sure ! But then you have to be prepared to see this kind of discussion coming again periodically.
<snip what="super-selector concept"/>
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.
Sure, it can be totally hidden behind the current <map:select> syntax, by allowing it to handle a new kind of selector (we already have 2 : Selector and SwitchSelector).
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>
Wow !
"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".
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.
So let's keep pipeline, but please add a FAQ entry about this ;-) <snip/>
I like the underlying concepts, but I think that:
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.
OK. So we have some strong and justified -1's against <map:flowmap>... 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]
