cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <giac...@apache.org>
Subject Re: [control flow] changes and new sample
Date Mon, 09 Sep 2002 11:20:54 GMT
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="..."/>

Giacomo


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


Mime
View raw message