cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Piroumian Konstantin <KPiroum...@protek.com>
Subject RE: [control flow] changes and new sample
Date Mon, 09 Sep 2002 11:25:22 GMT
> From: Giacomo Pati [mailto:giacomo@apache.org] 
> 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: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message