Re: [vote] finilizing the pending votes on flow [was Re: [RT] Flow/Sitemap Integration]
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
> > 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 ;-)
>
>
>
> >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 ...
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: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: [RT] Flow/Sitemap Integration
Michael Melhem wrote: On Tue, Jan 14, 2003 at 04:52:43PM +, Stefano Mazzocchi wrote: Michael Melhem wrote: Hmmm, but if we get that far, then isn't just syntax sugar for ??? 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: ... 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 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 and 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 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 and are similar, but conceptually they are different. Using 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). Hmmmbut im still in two minds about this. :) Me too. While I do see value in the concept of separation, I think that we might be closing the door to creative uses of the flow layer that might end up making the 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 component (as suggested above), the question then becomes, how do we get the 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 <[EMAIL PROTECTED]> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [RT] Flow/Sitemap Integration
Michael Melhem / Stefano Mazzocchi wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > flow="registerUser"/> > > > > > > > > > > > > > > > > > >... > > > > > > > > > > > >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 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 and 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 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 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. ... ... 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 -part should match before the 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 and are > similar, but conceptually they are different. Using 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). Hmmmbut 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 component (as suggested above), the question then > > >becomes, how do we get the 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: - should "flow-hooks within the pipelines" be removed? - names of the flow elements (scripts, call-function, continue) - allowing the cocoon protocol calling scripts? (I'm in favor of it because this could become a *really* cool feature!) Regards, Reinhard > > Regards, > Michael > > > > > -- > > Stefano Mazzocchi <[EMAIL PROTECTED]> > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [RT] Flow/Sitemap Integration
On Tue, Jan 14, 2003 at 04:52:43PM +, Stefano Mazzocchi wrote: > Michael Melhem wrote: > > >>Hmmm, but if we get that far, then > >> > >> > >> > >> > >> > >>isn't just syntax sugar for > >> > >> > >> > >> > >> > >> > >> > >>??? > > > > > >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: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >... > > > > > > > >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 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 and 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 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 and are similar, but conceptually they are different. Using 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). Hmmmbut im still in two minds about this. :) > > >If we use component (as suggested above), the question then > >becomes, how do we get the 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?? Regards, Michael > > -- > Stefano Mazzocchi <[EMAIL PROTECTED]> > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [RT] Flow/Sitemap Integration
On Tue, 14 Jan 2003, Ovidiu Predescu wrote: Hi Ovidiu!! :) > My 2 cents here. I haven't read the whole discussion thread, so please > illuminate me if I'm missing the point. > > Why can't we use the same syntax as today and extend the treeprocessor > to prevent stuff from being added before and after the > element? It seems to me this is the most simple thing we can do, > without requiring the user to use a reference manual each time they > want to modify the sitemap. Well...IMHO, the chief objection to this is that flow-mappings are _not_ pipelines and should not live in the pipelines section. Infact flow-mappings/hooks currently ignore the pipelines they are defined in. (See the initial posting in this thread for a more thorough reasoning as to why flow-mappings/hooks are not pipelines) The idea was too move the flow-mappings out of the pipelines section and into the flow section. This way you have all the flow stuff defined together in a "flow-contoller" for the sitemap. Regards, Michael > > Regards, > Ovidiu > > On Tuesday, Jan 14, 2003, at 08:52 US/Pacific, Stefano Mazzocchi wrote: > > > Michael Melhem wrote: > > > >>> Hmmm, but if we get that far, then > >>> > >>> > >>> > >>> > >>> > >>> isn't just syntax sugar for > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> ??? > >> 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: > >> > >> > >> > >> > >> > >> > >> > >> > >> > >>>> flow="registerUser"/> > >> > >> > >> > >> > >> ... > >> > >> > >> 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 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 and 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) > > > >> If we use component (as suggested above), the question then > >> becomes, how do we get the 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? > > > > -- > > Stefano Mazzocchi <[EMAIL PROTECTED]> > > > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, email: [EMAIL PROTECTED] > > > > > -- > Ovidiu Predescu <[EMAIL PROTECTED]> > http://www.google.com/search?btnI=&q=ovidiu (Are you feeling lucky?) > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [RT] Flow/Sitemap Integration
My 2 cents here. I haven't read the whole discussion thread, so please illuminate me if I'm missing the point. Why can't we use the same syntax as today and extend the treeprocessor to prevent stuff from being added before and after the element? It seems to me this is the most simple thing we can do, without requiring the user to use a reference manual each time they want to modify the sitemap. Regards, Ovidiu On Tuesday, Jan 14, 2003, at 08:52 US/Pacific, Stefano Mazzocchi wrote: Michael Melhem wrote: Hmmm, but if we get that far, then isn't just syntax sugar for ??? 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: ... 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 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 and 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) If we use component (as suggested above), the question then becomes, how do we get the 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? -- Stefano Mazzocchi <[EMAIL PROTECTED]> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- Ovidiu Predescu <[EMAIL PROTECTED]> http://www.google.com/search?btnI=&q=ovidiu (Are you feeling lucky?) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [RT] Flow/Sitemap Integration
Michael Melhem wrote: Hmmm, but if we get that far, then isn't just syntax sugar for ??? 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: ... 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 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 and 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) If we use component (as suggested above), the question then becomes, how do we get the 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? -- Stefano Mazzocchi <[EMAIL PROTECTED]> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [RT] Flow/Sitemap Integration
On Thu, 9 Jan 2003, Stefano Mazzocchi wrote: > Michael Melhem wrote: > > > >>>If it is decided that best practice is to disallow actions > >>>and routing components around flow calls:- > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>>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: > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>>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. > > well, a syntax such as > > > > > doesn't leave room for much pluggability of matching. > > >>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: > > > > > > > > We only constrain the sitemap markup within the the tags > > to enforce "best practice" (and to make the mapping syntax more > > compact and readable). We do not require new flowmap matcher > > componets etc. > > Hmmm, but if we get that far, then > > > > > > isn't just syntax sugar for > > > > > > > > ??? 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. if we agree that something like the following sitemap syntax is desirable: ... 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) We could use the 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. If we use component (as suggested above), the question then becomes, how do we get the 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?. Regards, Michael Melhem > > -- > Stefano Mazzocchi <[EMAIL PROTECTED]> > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [RT] Flow/Sitemap Integration
Michael Melhem wrote: 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. Agreed. The hard part is to identify what a pipeline is. Originally, a pipeline has been identified as a static (means non-runtime-based) assembly of filtering components and adaptors. That was easy. Then came actions which changed that. And now pipeline-state-aware selection has been shown as necessary for meaninful validation at transformation stage. I fear that as we move along, we are adding more and more 'procedural' (say run-time) concepts to the pipelines making them harder to describe with a markup language. 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 and I would suggest flow have matching preference before the . 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. Very good point. If it is decided that best practice is to disallow actions and routing components around flow calls:- 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: 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. well, a syntax such as doesn't leave room for much pluggability of matching. 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: We only constrain the sitemap markup within the the tags to enforce "best practice" (and to make the mapping syntax more compact and readable). We do not require new flowmap matcher componets etc. Hmmm, but if we get that far, then isn't just syntax sugar for ??? -- Stefano Mazzocchi <[EMAIL PROTECTED]> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
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. > > > > > > > > > > > > > > > > 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: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This way we actually define the "uber-contoller" for the sitemap > > in one place leaving the pipeline section as follows: > > > > > > > > ... > > > > > > > > > > > > > > > > > > > > > > > > > > ... > > > > > > This way (with most actions and flow logic
RE: [RT] Flow/Sitemap Integration
Stefano Mazzocchi wrote: > Hunsberger, Peter wrote: >> Stefano Mazzocchi wrote: >> I don't think I will! However, when doing architecture you always >> have to ask if inverting a control flow makes sense; sometimes >> abstractions suddenly become obvious or new use cases jump out. > > Oh totally. That's why I take time replying to your messages even if > they might sound too "devil's advocate"-ish to many here. ;-) Who moi? Never... ;-) I guess there are two things that drive me to spend the time worrying about how the Cocoon architecture will shake out in the long run: 1) Our commitment to using Cocoon. Even though we're pretty careful to use only standard XSLT it would still take a lot of work to rebuild our application as a normal Servlet. We've got working code that doesn't use Cocoon but it would be a lot of work to extend it to do all the things that the Cocoon version does and it's likely that the subsequent maintenance costs would also be high. 2) A general interest in data driven architectures. I think this makes us somewhat different than much of the regular Cocoon community (which is probably much more procedural logic driven). As such, it's worth while spending time trying to determine if and how much the two sets of requirements can merge. To many people the whole idea of data driven architectures is so foreign that they immediately think that they can't scale; but ultimately computing is computing and all logic is data, it's just the algorithms that exploit the data that differ, so I do hold out some hope that our requirements can fit with the rest of the Cocoon communities. >> If one was to do such a thing >> with the Cocoon sitemap obviously you'd have to allow the current >> semantics to continue to work so you'd introduce some complete new >> concept (what's the inversion of a pipeline?...) > > Not only that. Everytime you add a new construct you are not adding just > *one*, but you are adding all possible combinations of that construct > with everything that was there already. > > This is why I'm always *very* careful about adding new functionality. Well, I don't think it's always N! combinations: there are restrictions on which components can be used with other components. But I understand your concern, in particular since when you invert a control flow what was formally a many to one mapping now may become a one to many mapping (but also the reverse may happen, which is one reason why you look at it in the first place). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [RT] Flow/Sitemap Integration
Hunsberger, Peter wrote: Stefano Mazzocchi wrote: Then don't propose it. I don't think I will! However, when doing architecture you always have to ask if inverting a control flow makes sense; sometimes abstractions suddenly become obvious or new use cases jump out. Oh totally. That's why I take time replying to your messages even if they might sound too "devil's advocate"-ish to many here. ;-) If one was to do such a thing with the Cocoon sitemap obviously you'd have to allow the current semantics to continue to work so you'd introduce some complete new concept (what's the inversion of a pipeline?...) Not only that. Everytime you add a new construct you are not adding just *one*, but you are adding all possible combinations of that construct with everything that was there already. This is why I'm always *very* careful about adding new functionality. Damn, that's exactly the reason why I wanted pluggable matchers. Are you saying this as a good thing or as a bad thing? The sitemap components interfaces were designed so that concerns remain separate. From that point on, I'm happy with *anything* that comes out of that. That means: I'm happy about people experimenting new functionality by adding more components that fit the architecture. I tend to me a little more nervous when people try to force the architecture to do stuff that it can already do but in other ways that break back-compatibility. Is there a problem going forward? Not at all! You can have the equivalent of mod_spelling as a matcher as well... or you could have that table stored into a database... it's up to your matching logic. But matching is a special concern and I want to keep that separate from flow and other sitemap components. Sounds very good to me. Good. If that was a patter, that would mean that you'd be calling possibly more than one function in the flowscript at the same time and I would *NOT* like this. That makes sense (I was assuming first match wins, but I can't see a reason to support it). In that case, you're back to my original assumption: unique names and you can hash map the whole works. Yep. Of course I'll probably always wonder if there aren't multiple types of URI matching... Totally, that's exactly the reason why the entire URI matching logic is pluggable and not built into the sitemap. -- Stefano Mazzocchi <[EMAIL PROTECTED]> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [RT] Flow/Sitemap Integration
Stefano Mazzocchi wrote: > Hunsberger, Peter wrote: Now, if the "type" was available in the flow, you could get different resources for the same flow. >>> >>>Well, how would Cocoon know how to match? Say I ask for '/dashboard' how >>>is the pipeline going to find out where to get the parameter in order to >>>match the user-level? >> >> It would have to come from some higher level Cocoon component... > > well.. > >> Essentially you'd invert the current pipeline flow: matchers/selectors >> outside of pipeline types. > > but *why* braking everybody's sitemap when we have something else that > works perfectly with our current semantic? > >> I don't think it's currently worth spending any >> energy discussing why such a thing would be a bad idea... > > Then don't propose it. I don't think I will! However, when doing architecture you always have to ask if inverting a control flow makes sense; sometimes abstractions suddenly become obvious or new use cases jump out. If one was to do such a thing with the Cocoon sitemap obviously you'd have to allow the current semantics to continue to work so you'd introduce some complete new concept (what's the inversion of a pipeline?...) >> >> Seems fair enough. If that's the case then the recent issue about matching >> internal resources seems relevant: shouldn't flow also match internal >> resources? > > Yes, and AFAIK it does. Someone had posted that they couldn't get it to work. Hadn't heard more since >>>Agreed. One way of solving this would be to have a way to generate a >>>flowscript out of a cocoon:/ pipeline. But we haven't decided if that is >>>a good thing or is FS. >> >> Well I can certainly see how it might be nice to generate your language >> dependant URI matching automagically... > > Well, it's damn easy to do it right now with a custom i18n-aware matcher: > > > > then this "i18n" matcher has a lookup table like this > > >mail >posta >poste >... > > > There is no need to alter the sitemap semantics for this and no need to > have the flow involved. > > Damn, that's exactly the reason why I wanted pluggable matchers. Are you saying this as a good thing or as a bad thing? Is there a problem going forward? > You can have the equivalent of mod_spelling as a matcher as well... or > you could have that table stored into a database... it's up to your > matching logic. > > But matching is a special concern and I want to keep that separate from > flow and other sitemap components. Sounds very good to me. >> Yes, I agree. It seems that there is a real reason for indirect URI mapping >> from flow to pipeline, but no real reason to allow multiple types of >> indirection. As such, the addition of map:map isn't needed, you can achieve >> the same thing by adding a new attribute to the existing pipeline. IE: >> >> >> ... >> >> >> But then the question of what to do with actions remains, (it seems too >> early to deprecate them ;-)... > > Oh, I totally agree here. > >> The other new question is now; is the "flow" attribute in the above a unique >> name (as per my original assumption), or in fact a pattern? > > If that was a patter, that would mean that you'd be calling possibly > more than one function in the flowscript at the same time and I would > *NOT* like this. That makes sense (I was assuming first match wins, but I can't see a reason to support it). In that case, you're back to my original assumption: unique names and you can hash map the whole works. Of course I'll probably always wonder if there aren't multiple types of URI matching... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [RT] Flow/Sitemap Integration
Hunsberger, Peter wrote: Stefano Mazzocchi wrote: 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. This comes at the matching issue the opposite way that I did initially: instead of assuming that it is a unique resource name the assumption seems to be that there is always a level of re-direction. We discussed whether there was a real need for this and although I thought it was interesting the only use case I could find was to allow systems external from Cocoon to also be controlled from the flow layer... Another need is internationalized URI spaces: say you want 'www.mail.com/webmail' for english and 'www.posta.it/posta' for italian, and so on, but don't want to rewrite your flowscript method names. Ahh, now there's a real use case... Yep. Also, indirection is a good protection against intrusive injection of scripting since it wan't be enough to inject an harmful script, but you also need to modify the sitemap to redirect to the method. It seems unlikely it would help much: most often script injection exploits a faulty POST handler. Having found such a beast, you can usually just round trip a bad form field. However, I suspect you're really suggesting that it may help stop cross site scripting exploits and that seems more likely? No, forget about it. I thought more about it and it doesn't really make sense what I said. Ingore. Now, if the "type" was available in the flow, you could get different resources for the same flow. Well, how would Cocoon know how to match? Say I ask for '/dashboard' how is the pipeline going to find out where to get the parameter in order to match the user-level? It would have to come from some higher level Cocoon component... well.. Essentially you'd invert the current pipeline flow: matchers/selectors outside of pipeline types. but *why* braking everybody's sitemap when we have something else that works perfectly with our current semantic? I don't think it's currently worth spending any energy discussing why such a thing would be a bad idea... Then don't propose it. You are hardcoding pattern matching capabilities in your pipeline and this is not very nice, IMHO. Well, no, it might not be hard coded pattern matching, (though my simple example was), each pipeline might still use generic pattern matching. What I was getting at is that there may be flow "types" that are orthogonal to the URI space in some applications. Being able to have some kind of generic flow type matching capability seems so far FS, but, if you're adding URI indirection it seems worth while to ask: are there different types of indirection? This is a good question. I'll have to think about it more. Right now I can't think of anything that would help me answer it. But my point is that pipeline 'type' should indicate *how* the pipeline operates for all the resources it receives. it's a URI-space agnostic setting and I'd like to keep it so. Seems fair enough. If that's the case then the recent issue about matching internal resources seems relevant: shouldn't flow also match internal resources? Yes, and AFAIK it does. Agreed. One way of solving this would be to have a way to generate a flowscript out of a cocoon:/ pipeline. But we haven't decided if that is a good thing or is FS. Well I can certainly see how it might be nice to generate your language dependant URI matching automagically... Well, it's damn easy to do it right now with a custom i18n-aware matcher: then this "i18n" matcher has a lookup table like this mail posta poste ... There is no need to alter the sitemap semantics for this and no need to have the flow involved. Damn, that's exactly the reason why I wanted pluggable matchers. You can have the equivalent of mod_spelling as a matcher as well... or you could have that table stored into a database... it's up to your matching logic. But matching is a special concern and I want to keep that separate from flow and other sitemap components. The only partial overlap is between matchers and selectors but for back compatibility we have to support both even if we find a way to get rid of one of them. If it is decided that best practice is to disallow actions and routing components around flow calls:- 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: 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
RE: [RT] Flow/Sitemap Integration
Stefano Mazzocchi wrote: >>> >>>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. >> >> >> This comes at the matching issue the opposite way that I did >> initially: instead of assuming that it is a unique resource name the >> assumption seems to be that there is always a level of re-direction. >> We discussed whether there was a real need for this and although I >> thought it was interesting the only use case I could find was to allow >> systems external from Cocoon to also be controlled from the flow >> layer... > > Another need is internationalized URI spaces: say you want > 'www.mail.com/webmail' for english and 'www.posta.it/posta' for italian, > and so on, but don't want to rewrite your flowscript method names. Ahh, now there's a real use case... > Also, indirection is a good protection against intrusive injection of > scripting since it wan't be enough to inject an harmful script, but you > also need to modify the sitemap to redirect to the method. It seems unlikely it would help much: most often script injection exploits a faulty POST handler. Having found such a beast, you can usually just round trip a bad form field. However, I suspect you're really suggesting that it may help stop cross site scripting exploits and that seems more likely? >> >> Now, if the "type" was available in the flow, you could get different >> resources for the same flow. > > Well, how would Cocoon know how to match? Say I ask for '/dashboard' how > is the pipeline going to find out where to get the parameter in order to > match the user-level? It would have to come from some higher level Cocoon component... Essentially you'd invert the current pipeline flow: matchers/selectors outside of pipeline types. I don't think it's currently worth spending any energy discussing why such a thing would be a bad idea... > You are hardcoding pattern matching capabilities in your pipeline and > this is not very nice, IMHO. Well, no, it might not be hard coded pattern matching, (though my simple example was), each pipeline might still use generic pattern matching. What I was getting at is that there may be flow "types" that are orthogonal to the URI space in some applications. Being able to have some kind of generic flow type matching capability seems so far FS, but, if you're adding URI indirection it seems worth while to ask: are there different types of indirection? >> I'm sure there other ways to do the same thing >> and this seems dangerous to me; this use case is wrong or at best >> weak, but perhaps there would be other real pipeline types that you >> might want to select from in this manner? > > I really don't see any. > > The pipeline "type" decides *how* the pipeline works internally, but it > doesn't influence the way the components work or the system matches > resources. > This seems to fragment concerns since it should be a flowscript's > concern to know how to save state and not a sitemap's one. > > But my point is that pipeline 'type' should indicate *how* the pipeline > operates for all the resources it receives. it's a URI-space agnostic > setting and I'd like to keep it so. Seems fair enough. If that's the case then the recent issue about matching internal resources seems relevant: shouldn't flow also match internal resources? 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. >> >> >> In a way, if you implement your XML spec to flow generator don't you >> get this for free? Or, in other-words, couldn't an XML flow spec and a >> flowmap be one and the same thing? It seems to me that if you can >> specify flow generation via a language external to the sitemap you >> don't really need a flow map? Yes, the issue of mapping names (or >> whatever) to URIs still exists, but your flow controller is already >> capable of that if you really need it... > > Agreed. One way of solving this would be to have a way to generate a > flowscript out of a cocoon:/ pipeline. But we haven't decided if that is > a good thing or is FS. Well I can certainly see how it might be nice to generate your language dependant URI matching automagically... If it is decided that best practice is to disallow actions and routing components around flow calls:- Then perhaps the flowmap can be further simplified by introducing a new sitemap element "map:map". This means we can rewrite the fl
Re: [RT] Flow/Sitemap Integration
Hunsberger, Peter wrote: 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. This comes at the matching issue the opposite way that I did initially: instead of assuming that it is a unique resource name the assumption seems to be that there is always a level of re-direction. We discussed whether there was a real need for this and although I thought it was interesting the only use case I could find was to allow systems external from Cocoon to also be controlled from the flow layer... Another need is internationalized URI spaces: say you want 'www.mail.com/webmail' for english and 'www.posta.it/posta' for italian, and so on, but don't want to rewrite your flowscript method names. Also, indirection is a good protection against intrusive injection of scripting since it wan't be enough to inject an harmful script, but you also need to modify the sitemap to redirect to the method. Infact, although flow function are defined within "pipeline sections", they ignore them. Now, discussions aside, *this* is a valid point and shows some 'hackiness' in the current semantics. I totally agree with you. This also suggests that you could abstract the pipeline type into some extra level of flow control. For example consider: ... ... ... Now, if the "type" was available in the flow, you could get different resources for the same flow. Well, how would Cocoon know how to match? Say I ask for '/dashboard' how is the pipeline going to find out where to get the parameter in order to match the user-level? You are hardcoding pattern matching capabilities in your pipeline and this is not very nice, IMHO. I'm sure there other ways to do the same thing and this seems dangerous to me; this use case is wrong or at best weak, but perhaps there would be other real pipeline types that you might want to select from in this manner? I really don't see any. The pipeline "type" decides *how* the pipeline works internally, but it doesn't influence the way the components work or the system matches resources. So, one thing could be to have where no continuation is ever kept and where continuations are created and kept. This seems to fragment concerns since it should be a flowscript's concern to know how to save state and not a sitemap's one. But my point is that pipeline 'type' should indicate *how* the pipeline operates for all the resources it receives. it's a URI-space agnostic setting and I'd like to keep it so. 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. In a way, if you implement your XML spec to flow generator don't you get this for free? Or, in other-words, couldn't an XML flow spec and a flowmap be one and the same thing? It seems to me that if you can specify flow generation via a language external to the sitemap you don't really need a flow map? Yes, the issue of mapping names (or whatever) to URIs still exists, but your flow controller is already capable of that if you really need it... Agreed. One way of solving this would be to have a way to generate a flowscript out of a cocoon:/ pipeline. But we haven't decided if that is a good thing or is FS. If it is decided that best practice is to disallow actions and routing components around flow calls:- 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: 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. 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?' Here you have an opportunity for all kinds of over design... You could add "type" to the flowmap to allow my expert, intermediate, beginner use case. You could also add "type" to t
RE: [RT] Flow/Sitemap Integration
Stefano Mazzocchi wrote: > Hi again Stefano, Peter Hunsberger here; I was watching for your reply to this since it seemed to get specific about some of the issues we had discussed more generally a couple of weeks ago. >> >> 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. This comes at the matching issue the opposite way that I did initially: instead of assuming that it is a unique resource name the assumption seems to be that there is always a level of re-direction. We discussed whether there was a real need for this and although I thought it was interesting the only use case I could find was to allow systems external from Cocoon to also be controlled from the flow layer... >> Infact, although flow function are defined within >> "pipeline sections", they ignore them. >> >> >> >> >> >> >> > > Now, discussions aside, *this* is a valid point and shows some > 'hackiness' in the current semantics. > > I totally agree with you. This also suggests that you could abstract the pipeline type into some extra level of flow control. For example consider: ... ... ... Now, if the "type" was available in the flow, you could get different resources for the same flow. I'm sure there other ways to do the same thing and this seems dangerous to me; this use case is wrong or at best weak, but perhaps there would be other real pipeline types that you might want to select from in this manner? >> 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. In a way, if you implement your XML spec to flow generator don't you get this for free? Or, in other-words, couldn't an XML flow spec and a flowmap be one and the same thing? It seems to me that if you can specify flow generation via a language external to the sitemap you don't really need a flow map? Yes, the issue of mapping names (or whatever) to URIs still exists, but your flow controller is already capable of that if you really need it... >> >> If it is decided that best practice is to disallow actions and routing >> components around flow calls:- >> >> >> >> >> >> >> >> 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: >> >> >> >> >> >> >> >> 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. > > 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?' Here you have an opportunity for all kinds of over design... You could add "type" to the flowmap to allow my expert, intermediate, beginner use case. You could also add "type" to the map:map to specify the type of matcher (and get regexp or whatever back). Or you could add a pseudo protocol support to the flow attribute and support multiple simultaneous flow controllers (and maybe have expert, intermediate, beginner flows as opposed to expert, intermediate, beginner resources). The mind boggles %-) ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [RT] Flow/Sitemap Integration
I know almost everybody is idle for the holydays, but I want to reply to this before I forgot :) 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 :) 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) - 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. 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. 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: This way we actually define the "uber-contoller" for the sitemap in one place leaving the pipeline section as follows: ... ... 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 and --- If it is decided that best practice is to disallow actions and routing components around flow calls:- 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: 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 lo
[RT] Flow/Sitemap Integration
Hi, Ok, here is a little "rant" on flow/sitemap intergration :) 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) 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. 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. 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. --- 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. Infact, although flow function are defined within "pipeline sections", they ignore them. 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. Much like defining a class interface. For example, one can define a flow for a sitemap like this: This way we actually define the "uber-contoller" for the sitemap in one place leaving the pipeline section as follows: ... ... 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. --- If it is decided that best practice is to disallow actions and routing components around flow calls:- 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: This way we enforce best practice and keep routing control in the flow and out of the sitemap. Best Regards, Michael Melhem - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
