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