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:-
> >>>
> >>> <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>
>
> ???
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:
<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)
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.
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?.
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]
