You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@cocoon.apache.org by Michael Melhem <mi...@ffzd0yt3.bank.dresdner.net> on 2003/01/08 17:07:19 UTC

Re: [RT] Flow/Sitemap Integration

On Mon, 23 Dec 2002, Stefano Mazzocchi wrote:

> I know almost everybody is idle for the holydays, but I want to reply to
> this before I forgot :)

Unfortunaltly my idle time is over and im now back in "freezing"
Germany. Hmmm...

>
> Michael Melhem wrote:
> > Hi,
> >
> > Ok, here is a little "rant" on flow/sitemap intergration :)
>
> First, let me tell you that I link your ranting style a lot :)

Please, dont encourage me! :P

>
> > 1. What Is A Cocoon Pipeline?
> >
> > There are at least two concepts of pipeline in cocoon.
> >
> > 1.1 The Sitemap Pipeline.
> >
> > A sitemap-pipeline basically acts as a "recipe" on how
> > to build a processing-pipeline. Sitemap-pipelines contain
> > information on the type of processing-pipeline to use, and the
> > set of processing components to be attached to them.
> >
> > Typically, the purpose of each "sitemap-pipeline uri"
> > is to build a specific processing-pipeline.
> >
> > (Of course entry points into pipelines/flows need not be URI's, one
> > can match on "whatever", but for purposes of this mail, I will
> > stick to URIs)
>
> And this might be a first strong hypthesis in your reasoning that must
> be taken into consideration.
>
> > 1.2 The Processing Pipeline
> >
> > There are several different types of Processing Pipelines,
> > noncaching, caching, caching-point, profiling, hintable etc..
> >
> > The processing pipeline is in effect the SAX-conducting "glue" or "pipe"
> > which holds the pipeline components together. Usually an XML stream
> > flows down this pipe and gets transformed by each of the
> > pipeline components until it gets serialized by the last
> > pipeline component - the serializer (no surprise here).
> >
> > 2. What is A Flow?
> >
> > A flow is controlled navigation through a set of
> > processing-pipelines.
>
> The above is slightly incorrect, I would say:
>
>   - a pipeline is the way cocoon uses to produces resources (readers can
> be seen as 'condensed pipelines' for non-XML resources)

Yes, at more abstract level, a processing pipeline can be described as
a resource-producer.

>
>   - a flow is controlled navigation thru a set of resources
>
> the difference is the level of indirection provided by the URI space
> that provides the contract between the two. This is important to be able
> to separate the flow from actual pipeline descriptions and keep concerns
> separate.
>
> > That is, the purpose of "flow uri" is _not_ to build a
> > processing-pipeline, but rather, to define a application specific
> > flow through a logical set of them.
>
> Again, the flow controls navigation between a logical set of
> 'resources', not pipelines. The fact that those resources are associated
> to pipelines is merely an implementation detail in this context.

Well the point here, no matter whether we use the word "pipeline" or
"resource", is that flows and resources/pipelines are fundimentally
different "beasts" and probably shouldnt be living in the same paddock.

>
> >
> > This means a "flow-uri" is not same as a "sitemap-pipeline uri".
> > Conceptually flow URIs are not part of pipelines at all, they are
> > extra-pipeline. They act on pipelines.
>
> I do see your point but still your terminology might be misleading...
> more comments below.
>
> > ---
> >
> > So I find the notion of "flow uri's" living side by side with
> > "sitemap-pipline uri's" inside pipeline sections a little awkward.
> > There seems to be some muddling of concerns here.
>
> Oh boy, it's already hard enough to indicate what is a good URI, if we
> start discussing what is a 'flow uri' compared to a 'resource uri' we
> get in trouble.
>
> > Infact, although flow function are defined within
> > "pipeline sections", they ignore them.
> >
> >
> > <map:pipeline type="has_no_ effect_on_flow_uri">
> >   <map:match pattern="loginFlowUri/">
> >     <map:call flow="login"/>
> >   </map:match>
> > </map:pipeline>
>
> Now, discussions aside, *this* is a valid point and shows some
> 'hackiness' in the current semantics.
>
> I totally agree with you.
>
> > Implementation details aside, IMO, it would much cleaner if we could
> > define a flow-uri mapping (a flowmap) and keep it together with the
> > flow defintion itself.
>
> Heck, my original intention was to separate the sitemap into sitemap
> (for resource) and flowmap (for flow)... but we didn't have an
> implementation back then, it was everything up in the air.... now we do
> have something that works, maybe we should start discussing this again.
>
> > For example, one can define a flow for a sitemap like this:
> >
> >   <map:flow language="JavaScript">
> >     <map:script src="prefs.js"/>
> >
> >     <map:flowmap>
> >       <map:match pattern="kont/*">
> >         <map:call continuation="{1}"/>
> >       </map:match>
> >
> >       <map:match pattern="login/">
> >         <map:call function="login"/>
> >       </map:match>
> >
> >       <map:match pattern="register/">
> >         <map:call function="registerUser"/>
> >       </map:match>
> >
> >       <map:match pattern="logout/">
> >        <map:call function="logout"/>
> >       </map:match>
> >     </map:flowmap>
> >   </map:flow>
> >
> > This way we actually define the "uber-contoller" for the sitemap
> > in one place leaving the pipeline section as follows:
> >
> >   <map:pipelines>
> >     <map:pipeline>
> >       ...
> >       <map:match pattern="body-examples/*/**.xml">
> >         <map:generate src="examples/{1}/pages/{2}.xsp" type="sp"/>
> >         <map:transform src="stylesheets/document2html.xsl"/>
> >         <map:serialize type="xml"/>
> >       </map:match>
> >
> >       <map:match pattern="body-**.xml">
> >         <map:generate src="docs/{1}.xml"/>
> >         <map:transform src="context://.../document2html.xsl"/>
> >         <map:serialize/>
> >       </map:match>
> >     </map:pipeline>
> >     ...
> >   </map:pipelines>
> >
> > This way (with most actions and flow logic moved into the flow),
> > sitemap-pipelines become just that, pipelines!
> >
> > Conceptually a client can either invoke pipelines via flow (indirectly),
> > or invoke a pipeline directly.
>
> Assuming you want to keep that semantics all in the sitemap (you don't
> specify so, but I would tend to see that)... we must define the order of
> matching preference between <flow> and <pipelines>

I would suggest flow have matching preference before the <pipelines>. If
a sitemap has a flowmap defined, then its likely that for the most part,
the sitemap recources are accessed via the flow and not directly.

>
> > ---
> >
> > If it is decided that best practice is to disallow actions
> > and routing components around flow calls:-
> >
> >       <map:match pattern="login/">
> >         <!-- no sitemap routing/Acting components allowed -->
> >         <map:call function="login"/>
> >         <!-- no sitemap routing/Acting components allowed -->
> >       </map:match>
> >
> > Then perhaps the flowmap can be further simplified by introducing
> > a new sitemap element "map:map". This means we can rewrite the
> > flowmap section as follows:
> >
> >     <map:flowmap>
> >       <map:map uri="login/"  flow="login">
> >       <map:map uri="register/"  flow="registerUser">
> >       <map:map uri="logout/" flow="logout">
> >     </map:flowmap>
> >
> > This way we enforce best practice and keep routing control
> > in the flow and out of the sitemap.
>
> Hmmm, this is an interesting concept but this doesn't only prevent the
> use actions before calls (something which I'd deeply love to see
> enforced, but that's my personal view, of course, and you all know my
> stand against actions) it also *forces* the flow calls to be tied to URI
> matching.

Why would this force us to tie flow calls only to uri matchers? The
treeprocessor when processing the flowmap would lookup existing
matcher components. So all existing matcher "types" are available.

>
> I wonder, is this the case? by getting rid of matchers, we are also
> getting rid of the ability to keep them pluggable... and first objection
> would be 'how do I match flow URI with regexp?'

My initial thoughts are that we do not get rid of matchers at all, but
rather, we specify the matcher type we want to use inside the map tag.

The following is how one would match flow URIs with regexp:

 <map:map matcher="regexp" uri="blah*" flow="blahFlow">

We only constrain the sitemap markup within the the <flowmap> tags
to enforce "best practice" (and to make the mapping syntax more
compact and readable). We do not require new flowmap matcher
componets etc.

Best Regards,
Michael Melhem

>
> I like your concepts, anyway, let's see what others have to say about this.
> --
> Stefano Mazzocchi                               <st...@apache.org>
> --------------------------------------------------------------------
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>


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

Re: [RT] Flow/Sitemap Integration

Posted by Stefano Mazzocchi <st...@apache.org>.

Michael Melhem wrote:
> On Tue, Jan 14, 2003 at 04:52:43PM +0000, Stefano Mazzocchi wrote:
> 
>>Michael Melhem wrote:
>>
>>
>>>>Hmmm, but if we get that far, then
>>>>
>>>><flowmap>
>>>> <map type="regexp" patter="blah*" flow="blahFlow"/>
>>>></flowmap>
>>>>
>>>>isn't just syntax sugar for
>>>>
>>>><pipeline>
>>>> <match type="regexp" pattern="blah*">
>>>>  <call function="blahFlow"/>
>>>> </match>
>>>></pipeline>
>>>>
>>>>???
>>>
>>>
>>>Hmm..Well maybe, but for the fact that flowmap section in not within the
>>>pipeline section (which I think we agreed is what we want)
>>>and that the treeprocessor would not allow actions or
>>>other routing components which would otherwise be allowed within the
>>>pipeline section.
>>
>>Good point.
>>
>>
>>>if we agree that something like the following sitemap syntax
>>>is desirable:
>>>
>>><map:sitemap>
>>> <map:components>
>>> </map:components>
>>>
>>> <map:flow>
>>>   <map:script>
>>>     <src="myflow.js">
>>>   </map:script>
>>>   <map:flowmap>
>>>     <map:map pattern="login/"  flow="login"/>
>>>     <map:map type="regexp" pattern="register*/"  flow="registerUser"/>
>>>     <map:map pattern="logout/" flow="logout"/>
>>>   </map:flowmap>
>>> </map:flow>
>>>
>>> <map:pipelines>
>>>   ...
>>> </map:pipelines>
>>></map:sitemap>
>>>
>>>We could define a flow mapping as a "matching" between a flow function
>>>and its corresponding entry point pattern (which could be an URI
>>>or whatever)
>>
>>True.
>>
>>
>>>We could use the <map:match> directly withing the flowmap to implement
>>>this, but this would not force the user to call a flow method and would
>>>not allow for the compact easy-to-read syntax above.
>>
>>But I'm pretty sure that people *will* want to extend that and will 
>>complain about the fact that <map> and <match> do, in fact, the same 
>>thing, but with different semantics and this won't please people (nor 
>>please my sense of semantic elegance, to tell you the truth)
> 
> 
> A map:map = map:match + map:call
> 
> Im not against using <map:match> here within the flowmap...but 
> I do have to ask wouldnt it suggest to the user (incorrectly) that this 
> is another a "pipeline" where they can assemble anything they like? 
> 
> Perhaps at the implementation level <map:match> and <map:map> are  
> similar, but conceptually they are different.  Using <map:map> will 
> encourage the user to think of the mapping as a single atomic 
> instruction and not try and "tinker" with other 
> components (routing or otherwise). Hmmm....but im still in two minds
> about this. :)

Me too. While I do see value in the concept of <flowmap> separation, I 
think that we might be closing the door to creative uses of the flow 
layer that might end up making the <flowmap> mappings as complex as the 
normal sitemap pipelines.

I'm starting to think that we should leave it as it is and see user 
feedback before trying to solve an issue that might not even exist.

>>>If we use <map:map> component (as suggested above), the question then
>>>becomes, how do we get the <map:map> component to match (URIs in
>>>the above case)?
>>>
>>>Is there a reason why we wouldnt use (under the hood) the
>>>already existing matcher components to the matching here?.
>>
>>No technical reason (that I can think of) but it's a purely semantical one.
>>
>>Granted that it makes sense to move the flow hooks from the pipeline, I 
>>think that we should reuse semantics where it makes sense, because 
>>people already made an effort to learn it and in that case we reduce 
>>their need to learn new stuff.
>>
>>Thoughts?
> 
> 
> What about issues like backwards compatibility. If we were to get the
> the go ahead form the list to implement this, would we still allow 
> flow-hooks within the pipelines sections as is the case now - for the
> sake of backward compatibility??

We are in alpha-mode for a reason. And the reason is *exactly* to try to 
do the *right* thing *before* we have to bind our back-compatibility 
effort to it.

When we designed the sitemap, it took us months to agree on the 
semantics and we kept moving it back and forward until nobody had 
anything to say about it.

I think that effort saved us a bunch of pain later on and I'm willing to 
follow the same path once again.

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



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

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

Posted by Sylvain Wallez <sy...@anyware-tech.com>.

Michael Melhem wrote:

>On Fri, Jan 17, 2003 at 04:20:17PM +0100, Sylvain Wallez wrote:
>  
>
<snip/>

>>OK. So we have some strong and justified -1's against <map:flowmap>...
>>    
>>
>
>Yes your argument is convincing, so perhaps we should put 
>the flowmap issue on the back-burner .. ;)
>
>One small point though, I still think flow differs from a pipeline
>because it contains information at more abstract level. As I noted
>earlier, IMHO a pipelines purpose regardless of redirects, forwardings, or
>actions is to describe a single "resource". While a flow describes 
>a logical set of "resources"...
>

I agree : the flow chooses among these resources depending on both the 
request and the application state. That's what I called a "computed 
forward".

>Anyway, its time for weekend..... :) 
>

Enjoy it, mate :-)

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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

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

Posted by Michael Melhem <mi...@fztig938.bank.dresdner.net>.

On Fri, Jan 17, 2003 at 04:20:17PM +0100, Sylvain Wallez wrote:
> Stefano Mazzocchi wrote:
> 
> >Sylvain Wallez wrote:
> >
> >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>...

Yes your argument is convincing, so perhaps we should put 
the flowmap issue on the back-burner .. ;)

One small point though, I still think flow differs from a pipeline
because it contains information at more abstract level. As I noted
earlier, IMHO a pipelines purpose regardless of redirects, forwardings, or
actions is to describe a single "resource". While a flow describes 
a logical set of "resources"...

Anyway, its time for weekend..... :) 

regards,
Michael

> 
> 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: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
> 

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

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

Posted by Sylvain Wallez <sy...@anyware-tech.com>.

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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

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

Posted by Stefano Mazzocchi <st...@apache.org>.

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                               <st...@apache.org>
--------------------------------------------------------------------



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

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

Posted by Sylvain Wallez <sy...@anyware-tech.com>.

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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

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

Posted by Reinhard Poetz <re...@gmx.net>.

Thank you very much! I thought that it would work the other way!

Regards,
Reinhard

> -----Original Message-----
> From: Christopher Oliver [mailto:res1cf5x@verizon.net]
> Sent: Friday, January 17, 2003 7:18 AM
> To: cocoon-dev@xml.apache.org
> Subject: Re: [vote] finilizing the pending votes on flow [was Re: [RT]
> Flow/SitemapIntegration]
> 
> 
> Hi Reinhard,
> 
> Just a warning, you should always use the "var" keyword with local 
> variables in JavaScript.  Your function should probably read:
> 
> function callPipeline(src) {
>     var xc = cocoon.componentManager.lookup( myXMLConsumer.ROLE );
>     var resolver = 
> cocoon.environment.getObjectModel().get("source-resolver");
>     var srce = resolver.resolveURI(src);
>     resolver.toSAX( srce, xc );
>     return xc;
> }
> 
> Without "var" you are creating global variables named "xc", "resolver", 
> "srce". .
> 
> Regards,
> 
> Chris
> 
> Reinhard Poetz wrote:
> 
> >For my flows I use a self-defined function which makes this for me:
> >
> >function callPipeline(src) {
> >    xc = cocoon.componentManager.lookup( myXMLConsumer.ROLE );
> >    resolver = 
> cocoon.environment.getObjectModel().get("source-resolver");
> >    srce = resolver.resolveURI(src);
> >    resolver.toSAX( srce, xc );
> >    return xc;
> >}
> >
> >  
> >
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
> 

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

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

Posted by Christopher Oliver <re...@verizon.net>.

Hi Reinhard,

Just a warning, you should always use the "var" keyword with local 
variables in JavaScript.  Your function should probably read:

function callPipeline(src) {
    var xc = cocoon.componentManager.lookup( myXMLConsumer.ROLE );
    var resolver = cocoon.environment.getObjectModel().get("source-resolver");
    var srce = resolver.resolveURI(src);
    resolver.toSAX( srce, xc );
    return xc;
}

Without "var" you are creating global variables named "xc", "resolver", 
"srce". .

Regards,

Chris

Reinhard Poetz wrote:

>For my flows I use a self-defined function which makes this for me:
>
>function callPipeline(src) {
>    xc = cocoon.componentManager.lookup( myXMLConsumer.ROLE );
>    resolver = cocoon.environment.getObjectModel().get("source-resolver");
>    srce = resolver.resolveURI(src);
>    resolver.toSAX( srce, xc );
>    return xc;
>}
>
>  
>



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

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

Posted by Reinhard Pötz <re...@gmx.net>.

> -----Original Message-----
> From: Stefano Mazzocchi [mailto:stefano@apache.org] 
> 
> 
> Reinhard Poetz wrote:
> 
> > There remains one open question for me: How to I get 'feedback' 
> > whether the called pipeline did its job well or not? And if 
> not, how 
> > to I get information about what happend (error message/status 
> > information)?
> > 
> > What do you think?
> 
> I think you are getting right to the bone of the problem and I don't 
> think I have a clear-cut solution... but I gotta go now, have to meet 
> Pier at a pub downtown and we don't want to make a nice english beer 
> wait, don't we? :)

Of course not ;-)

A further issue are asynchronous calls of pipelines in the case 

 - you do not want to wait for response of the backend 
 - or the backend is at the moment of calling it not available
 - or you want to guarantee the call of the backend

Regards,
Reinhard


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

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

Posted by Stefano Mazzocchi <st...@apache.org>.

Reinhard Poetz wrote:

> There remains one open question for me: How to I get 'feedback' whether the
> called pipeline did its job well or not? And if not, how to I get
> information about what happend (error message/status information)?
> 
> What do you think?

I think you are getting right to the bone of the problem and I don't 
think I have a clear-cut solution... but I gotta go now, have to meet 
Pier at a pub downtown and we don't want to make a nice english beer 
wait, don't we? :)

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

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

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

Posted by Reinhard Poetz <re...@gmx.net>.

> > For my flows I use a self-defined function which makes this for me:
> >
> > function callPipeline(src) {
> >     xc = cocoon.componentManager.lookup( myXMLConsumer.ROLE );
> >     resolver =
> cocoon.environment.getObjectModel().get("source-resolver");
> >     srce = resolver.resolveURI(src);
> >     resolver.toSAX( srce, xc );
> >     return xc;
> > }
> >
> > The component myXMLConsumer has a method <code>public String
> > getDocument()</code> ... mabe there is a better/more elegant way, but it
> > works for me ;-)
>
> nonono, careful. You are calling a pipeline to have its data as an
> object model to play with. While this is fair, I don't like it at all
> and would not want it included in system.js. It looks like an hack from
> miles away (sorry, no offense, just stating my impressions honestly)

After having a second look at my sources I think I don't really need the
part generating the string. This would reduce it to following lines:

function callPipeline( src ) {
  var xc = cocoon.componentManager.lookup( anyXMLConsumer.ROLE );
  var resolver = cocoon.environment.getObjectModel().get(
"source-resolver" );
  var srce = resolver.resolveURI( src );
  resolver.toSAX( srce, xc );
}

Then the pipeline called with "src" makes everything on its own.
  1. gather the necessary information from somewhere (input modules,
database, ...)
  2. save the information (send a mail, write to cvs, write to disc, ...)

There remains one open question for me: How to I get 'feedback' whether the
called pipeline did its job well or not? And if not, how to I get
information about what happend (error message/status information)?

What do you think?

Reinhard







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

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

Posted by Reinhard Poetz <re...@gmx.net>.

Ugo Cei wrote:
>
>
> Reinhard Poetz wrote:
> > Therefore I'll come up with a solution of using the flow as
> controller for
> > XMLForms - a 'pre-alpha' version is already running at my laptop. I know
> > that my solution is far from being perfect (continuations can
> be very tricky
> > ...) but I want to learn and the feedback will make me learn
> new things and
> > this will make our/my solutions better.
>
> Do you mean something like this?
>
> var form = getForm("progetto-form", progetto,
> 	"context://flows/workflow-schema.xml");
> while (true) {
> 	form.save(cocoon.environment.getObjectModel(), "request");
> 	sendPageAndWait("progetto-form",  { "username" : user.name });
> 	form.populate(cocoon.environment.getObjectModel());
> 	form.validate("progetto");
> 	if (form.getViolations() != null &&
> 	    form.getViolations().size() > 0) {
> 		continue;
> 	break;
> }
>


Yes. (Additionally?) I use continuations to move forward/backward within the
flow. This works well but sometimes I get some strange results after using
the previous/next button of the *browser*.
My next step will be controlling Ivelin's XMLForm example with a flow
script. If this works I'll submit a patch that enables others to have a look
at it.

Reinhard




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

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

Posted by Ugo Cei <u....@cbim.it>.

Reinhard Poetz wrote:
> Therefore I'll come up with a solution of using the flow as controller for
> XMLForms - a 'pre-alpha' version is already running at my laptop. I know
> that my solution is far from being perfect (continuations can be very tricky
> ...) but I want to learn and the feedback will make me learn new things and
> this will make our/my solutions better.

Do you mean something like this?

var form = getForm("progetto-form", progetto,
	"context://flows/workflow-schema.xml");
while (true) {
	form.save(cocoon.environment.getObjectModel(), "request");
	sendPageAndWait("progetto-form",  { "username" : user.name });
	form.populate(cocoon.environment.getObjectModel());
	form.validate("progetto");
	if (form.getViolations() != null &&
	    form.getViolations().size() > 0) {
		continue;
	break;
}


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

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

Posted by Ugo Cei <u....@cbim.it>.

[I'm resending this, since the first time I managed to inadvertently cut 
the last part of the message.]

Reinhard Poetz wrote:

 > Therefore I'll come up with a solution of using the flow as 
controller for
 > XMLForms - a 'pre-alpha' version is already running at my laptop. I  know
 > that my solution is far from being perfect (continuations can be very 
tricky
 > ...) but I want to learn and the feedback will make me learn new 
things and
 > this will make our/my solutions better.

Do you mean something like this?

var form = getForm("progetto-form", progetto,
     "context://flows/workflow-schema.xml");
while (true) {
     form.save(cocoon.environment.getObjectModel(), "request");
     sendPageAndWait("progetto-form",  { "username" : user.name });
     form.populate(cocoon.environment.getObjectModel());
     form.validate("progetto");
     if (form.getViolations() != null &&
         form.getViolations().size() > 0) {
         continue;
     break;
}

I'm working on this for a customer. At the moment it basically works for 
single page forms, but there's a lot of code duplication that I'd like 
to factor out before submitting anything to the public.

How about joining efforts instead of duplicating them?

	Ugo


-- 
Ugo Cei - http://www.beblogging.com/blog/


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

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

Posted by Reinhard Poetz <re...@gmx.net>.

> -----Original Message-----
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
> Sent: Friday, January 17, 2003 1:27 PM
> To: cocoon-dev@xml.apache.org
> Subject: Re: [vote] finilizing the pending votes on flow [was Re: [RT]
> Flow/SitemapIntegration]
>
>
> Reinhard Poetz wrote:
> > Stefano Mazzocchi wrote:
> >
> > <snip>
> >
> >>Let me add:
> >>
> >>  - make a new method that allows the flow to call a pipeline and pass a
> >>different output stream. This will allow to use pipelines as tools to
> >>serialize things, say, to disk or to other means.
> >>
> >>What do you think?
> >
> > </snip>
> >
> > I think you mean a function in the system.js, don't you?
>
> Yes, exactly. A function equivalent to sendPageAndContinue() that I can
> use to call a pipeline but to use it orthogonally from the normal stream
> of data that flows from the request to the response.
>
> This is very useful, for example, to save stuff to disk or to CVS or to
> any other repository and will finally, IMO, give an end to the need for
> a forked pipeline that goes in two different places.
>
> > For my flows I use a self-defined function which makes this for me:
> >
> > function callPipeline(src) {
> >     xc = cocoon.componentManager.lookup( myXMLConsumer.ROLE );
> >     resolver =
> cocoon.environment.getObjectModel().get("source-resolver");
> >     srce = resolver.resolveURI(src);
> >     resolver.toSAX( srce, xc );
> >     return xc;
> > }
> >
> > The component myXMLConsumer has a method <code>public String
> > getDocument()</code> ... mabe there is a better/more elegant way, but it
> > works for me ;-)
>
> nonono, careful. You are calling a pipeline to have its data as an
> object model to play with. While this is fair, I don't like it at all
> and would not want it included in system.js. It looks like an hack from
> miles away (sorry, no offense, just stating my impressions honestly)

I had the same impression but no idea of making it better. I'm looking
forward to reading your RT.
(I have no problem with other ideas and valuable feedback from people who
have the same/different needs - I think that's the big difference between
commercial software and open source software because commercial software is
nearly always focused and once written and working only reviewed if problems
arise.)

Therefore I'll come up with a solution of using the flow as controller for
XMLForms - a 'pre-alpha' version is already running at my laptop. I know
that my solution is far from being perfect (continuations can be very tricky
...) but I want to learn and the feedback will make me learn new things and
this will make our/my solutions better.

One note: If I look back the last two years it's really incredible what I
learned about design patterns (coming from the M$ visual programming world I
have never heard of it before), java programming, xml, xslt, ...  only by
studying Cocoon and Avalon concepts/source code/examples and
following/taking part in disussions. I don't know which university/school
can offer an education at this level - maybe I'm wrong.

What are the experiences of others?

Reinhard

>
> What I want is something different.
>
> I'll come up with an RT later today or tomorrow.
>
> For now, consider it separated from this vote since it has not been
> discussed well and I want more feedback on it.
>
> --
> Stefano Mazzocchi                               <st...@apache.org>
> --------------------------------------------------------------------

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

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

Posted by Stefano Mazzocchi <st...@apache.org>.

Reinhard Poetz wrote:
> Stefano Mazzocchi wrote:
> 
> <snip>
> 
>>Let me add:
>>
>>  - make a new method that allows the flow to call a pipeline and pass a
>>different output stream. This will allow to use pipelines as tools to
>>serialize things, say, to disk or to other means.
>>
>>What do you think?
> 
> </snip>
> 
> I think you mean a function in the system.js, don't you?

Yes, exactly. A function equivalent to sendPageAndContinue() that I can 
use to call a pipeline but to use it orthogonally from the normal stream 
of data that flows from the request to the response.

This is very useful, for example, to save stuff to disk or to CVS or to 
any other repository and will finally, IMO, give an end to the need for 
a forked pipeline that goes in two different places.

> For my flows I use a self-defined function which makes this for me:
> 
> function callPipeline(src) {
>     xc = cocoon.componentManager.lookup( myXMLConsumer.ROLE );
>     resolver = cocoon.environment.getObjectModel().get("source-resolver");
>     srce = resolver.resolveURI(src);
>     resolver.toSAX( srce, xc );
>     return xc;
> }
> 
> The component myXMLConsumer has a method <code>public String
> getDocument()</code> ... mabe there is a better/more elegant way, but it
> works for me ;-)

nonono, careful. You are calling a pipeline to have its data as an 
object model to play with. While this is fair, I don't like it at all 
and would not want it included in system.js. It looks like an hack from 
miles away (sorry, no offense, just stating my impressions honestly)

What I want is something different.

I'll come up with an RT later today or tomorrow.

For now, consider it separated from this vote since it has not been 
discussed well and I want more feedback on it.

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

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

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

Posted by Reinhard Poetz <re...@gmx.net>.

Stefano Mazzocchi wrote:

<snip>
> Let me add:
>
>   - make a new method that allows the flow to call a pipeline and pass a
> different output stream. This will allow to use pipelines as tools to
> serialize things, say, to disk or to other means.
>
> What do you think?
</snip>

I think you mean a function in the system.js, don't you?

For my flows I use a self-defined function which makes this for me:

function callPipeline(src) {
    xc = cocoon.componentManager.lookup( myXMLConsumer.ROLE );
    resolver = cocoon.environment.getObjectModel().get("source-resolver");
    srce = resolver.resolveURI(src);
    resolver.toSAX( srce, xc );
    return xc;
}

The component myXMLConsumer has a method <code>public String
getDocument()</code> ... mabe there is a better/more elegant way, but it
works for me ;-)

Regards,
Reinhard

>
> --
> Stefano Mazzocchi                               <st...@apache.org>
> --------------------------------------------------------------------
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>


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

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

Posted by Stefano Mazzocchi <st...@apache.org>.

Reinhard Poetz wrote:
> Michael Melhem / Stefano Mazzocchi wrote:
> 
> <snip>
> 
>>>><map:sitemap>
>>>> <map:components>
>>>> </map:components>
>>>>
>>>> <map:flow>
>>>>   <map:script>
>>>>     <src="myflow.js">
>>>>   </map:script>
>>>>   <map:flowmap>
>>>>     <map:map pattern="login/"  flow="login"/>
>>>>     <map:map type="regexp" pattern="register*/"
>>
>>flow="registerUser"/>
>>
>>>>     <map:map pattern="logout/" flow="logout"/>
>>>>   </map:flowmap>
>>>> </map:flow>
>>>>
>>>> <map:pipelines>
>>>>   ...
>>>> </map:pipelines>
>>>></map:sitemap>
>>>>
>>>>We could define a flow mapping as a "matching" between a flow function
>>>>and its corresponding entry point pattern (which could be an URI
>>>>or whatever)
>>>
>>>True.
>>>
>>>
>>>>We could use the <map:match> directly withing the flowmap to implement
>>>>this, but this would not force the user to call a flow method and would
>>>>not allow for the compact easy-to-read syntax above.
>>>
>>>But I'm pretty sure that people *will* want to extend that and will
>>>complain about the fact that <map> and <match> do, in fact, the same
>>>thing, but with different semantics and this won't please people (nor
>>>please my sense of semantic elegance, to tell you the truth)
>>
>>A map:map = map:match + map:call
>>
>>Im not against using <map:match> here within the flowmap...but
>>I do have to ask wouldnt it suggest to the user (incorrectly) that this
>>is another a "pipeline" where they can assemble anything they like?
> 
> 
> I don't think so because the flow related stuff is outside of
> <map:pipelines>...</map:pipelines>. And a second arguement: the sitemap
> interpreter will not allow such constructs.
> 
> Therefore I would use following XML to declare the mappings to flow scripts.
> ...
> </map:components>
> <map:flow>
>    <map:scripts language="JavaScript">
>        <map:script src="scripts.js"/>
>    </map:scripts>
>    <map:flowmap>
>       <map:match pattern="xxx">
>          <map:flow call-function="xxx()"/>
>       </map>
>       <map:match type="request-parameter" pattern="cont-id">
>          <map:flow continue-with="{1}"/>
>       </map:match>
>    </map:flowmap>
> </map:flow>
> <map:pipelines>
> ...
> 
> This would have following advantages:
>  - reuse of the matchers
>  - easier for existing cocoon users to understand the mapping
>    between uri/request-parameter/what-ever  <---> flow
>  - possible to submit parameters to the matcher AND to the function
>  - clear separation between pipelines and flows
> 
> and
>  - (as already mentioned in this thread): the <map:flow>-part should match
>    before the <map:pipelines> part
> 
> ... disclaimer:
> I know that element/attribute names are important but my point in this mail
> is the structure - so please don't discuss why I named elements this ;-)
> 
> 
> 
>>Perhaps at the implementation level <map:match> and <map:map> are
>>similar, but conceptually they are different.  Using <map:map> will
>>encourage the user to think of the mapping as a single atomic
>>instruction and not try and "tinker" with other
>>components (routing or otherwise). Hmmm....but im still in two minds
>>about this. :)
> 
> 
> What do you mean exactly?
> What I *really* need is a way to redirect to a URI which is mapped to a
> flowscript - which is currently possible.
> 
> 
>>>>If we use <map:map> component (as suggested above), the question then
>>>>becomes, how do we get the <map:map> component to match (URIs in
>>>>the above case)?
>>>>
>>>>Is there a reason why we wouldnt use (under the hood) the
>>>>already existing matcher components to the matching here?.
>>>
>>>No technical reason (that I can think of) but it's a purely
>>
>>semantical one.
>>
>>>Granted that it makes sense to move the flow hooks from the pipeline, I
>>>think that we should reuse semantics where it makes sense, because
>>>people already made an effort to learn it and in that case we reduce
>>>their need to learn new stuff.
> 
> 
> Exactly!
> 
> 
> 
>>>Thoughts?
>>
>>What about issues like backwards compatibility. If we were to get the
>>the go ahead form the list to implement this, would we still allow
>>flow-hooks within the pipelines sections as is the case now - for the
>>sake of backward compatibility??
> 
> 
> I think there should be a *final* vote about the semantics without
> considering backward compatibilty:

I find myself resonating with your vision entirely!

>  - should "flow-hooks within the pipelines" be removed?

No, at least for now. I would say let's do it and see what happens.

>  - names of the flow elements (scripts, call-function, continue)

I think we settled down on that issue, didn't we?

>  - allowing the cocoon protocol calling scripts?
>   (I'm in favor of it because this could become a *really* cool feature!)

Yes, I'm definately +1 on this after some careful thinking.

Let me add:

  - make a new method that allows the flow to call a pipeline and pass a 
different output stream. This will allow to use pipelines as tools to 
serialize things, say, to disk or to other means.

What do you think?

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



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