> From: Giacomo Pati [mailto:[EMAIL PROTECTED]] > On Sun, 8 Sep 2002, Stefano Mazzocchi wrote: > > Per-Olof Norén wrote: > > > > > So the the controller is defined and used as the following? > > > > > > <map:controller language="JavaScript"> > > > <map:script src="prefs.js"/> > > > <map:script src="some-other-script.js"/> > > > </map:controller> > > > .... > > > <map:match pattern="calc/*"> > > > <map:flow function="calculator" continuation="{1}"/> > > > </map:match> > > > > > > +1 on that. Seems to me the overall usage will be the same. > > > > Call me picky, but I have a few issues with the above. > > > > 1) <map:controller> is clearly MVC-oriented. I find this > incoherent with > > the rest of the sitemap semantics. It is true that 'flow' > takes the role > > of a 'controller' if we apply the MVC pattern on top of > cocoon, but I > > *do*not* think we should marry the MVC pattern that close. > Expecially > > because there is no explicit indication of the rest of the pattern's > > concerns (what is a view in Cocoon? that's not an easy answer) > > > > My point is: Cocoon is a framework and uses separation of > concerns as > > the main metapattern. Why should we restrict our semantics > to only *one* > > of the possible ways of separating concerns (that is: MVC)? > Expecially > > when people want to differentiate and call MVC++ or Model2 > or Model2+1 > > or stuff like that. > > > > My perception is that MVC is a suggestion on how to start, > not the end > > of the path. Flow is a much more abstract concept than > 'controller' and > > is more coherent with the rest of the sitemap semantics. > > > > My proposal is to change > > > > <map:controller language="JavaScript"> > > <map:script src="prefs.js"/> > > <map:script src="some-other-script.js"/> > > </map:controller> > > > > with > > > > <map:flow language="JavaScript"> > > <map:script src="prefs.js"/> > > <map:script src="some-other-script.js"/> > > </map:flow> > > > > 2) This means that we have to come up with something different to > > replace <map:flow> inside the pipelines and acts as the connection > > between the pipelines and the flow. > > > > <map:match pattern="calc/*"> > > <map:??? function="calculator" continuation="{1}"/> > > </map:match> > > > > Here there is something to note: > > > > a) the tags inside the pipelines indicate an action (generate, > > transform, serialize, match, select, act, read). The > question becomes: > > what action is the above unknown tag performs? > > > > Verbosely, the above line is 'passing control to the flow layer'. > > Unfortunately, something like > > > > <map:match pattern="calc/*"> > > <map:control function="calculator" continuation="{1}"/> > > </map:match> > > > > would not make the action so self-evident (and will > conflict with the > > 'controller' semi-pattern again) > > > > "flow" is useless if used as an action. I would be -1 on > its use in this > > context. > > > > "call" might be one of the best choices: > > > > <map:match pattern="calc/*"> > > <map:call function="calculator" continuation="{1}"/> > > </map:match> > > > > which is still much different from > > > > <map:match pattern="calc/*"> > > <map:call resource="blah"/> > > </map:match> > > > > "delegate-to" is meaningful but it clearly sucks. > > > > Hmmm, anybody with a better alternative? > > <map:adapt function="..."/> > > <map:work function="..."/> > > <map:process function="..."/>
<map:function name="..."/> ;-) Konstantin > > Giacomo > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
