Michael Melhem wrote:
Agreed.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.
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 <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.
Very good point.
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.
well, a syntax such as
<map:flowmap>
<map:map uri="login/" flow="login">
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: <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.
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> ??? -- Stefano Mazzocchi <[EMAIL PROTECTED]> -------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
