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 <call function/> > 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 > >>> > >>> <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) > > > >> 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? > > > > -- > > 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]
