cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [vote] finilizing the pending votes on flow [was Re: [RT] Flow/Sitemap Integration]
Date Fri, 17 Jan 2003 12:43:12 GMT
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).
> 
> 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>

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.

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

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

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

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.

-- 
Stefano Mazzocchi                               <stefano@apache.org>
--------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message