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