cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: sitemap, jx and flow design (was: servicemanager and jxtg)
Date Tue, 25 Jan 2005 16:02:29 GMT
BURGHARD √Čric wrote:

>Daniel Fagerstrom wrote:

>I'm not obsessed trust me (by the sitemap at least :-).
>But certainly i was not clear. I dislike actions (which is the kind of
>control you don't want in the sitemap too), and prefer flow for controling
>workflow as you do. My previous example has nothing to do with workflow.
>It's a pure template that is feeded (respectfull to IoC and SoC) by the
>sitemap controller (as you probably know flow is not the only one
>controller) in one line and with a syntax which everybody could understand.
><pipeline match="allinone">
>  <generate type="jx" src="..">
>   <!-- pass authentication dom to jx -->
>    <parameter name="auth" dom="{session-context:authentication}"/>
>  </generate>
>  ...
>The same example could be done in sitemap+flow, but look how !
><flow language="javascript">
>  <script src="myfunc.js"/>
><pipeline match="begin">
> <call function="myfunc">
><pipeline match="returntositemap">
>  <generate type="jx" src="..."/>
>  ...
>function myfunc () {
> uri = "cocoon:/getuser";
> parser =
>        resolver =
>        source = resolver.resolveURI(uri);
>        var is = new
>        is.setSystemId(source.getURI());
>        dom = parser.parseDocument(is);
>$cocoon.SendPage("returntositemap", dom)
>Whow ! that's a lot of things for beginners. But that's not really
>important. The worst is that i need to go though flow (again no workflow
>here), and that it blur my vision of what's happening between begin and
>returntositemap. All that for a poor little template.
I have never disputed that things might be clumsy now, I just think we 
should focus on getting the flowscript way better, instead of adding 
things that makes the sitemap more of a programming language, by 
handling a more diverse set of datatypes then strings. With what I 
propse your example would be:

<flow language="javascript">
  <script src="myfunc.js"/>

<pipeline match="begin">
 <call function="myfunc">
 <generate type="jx" src="..."/>

function myfunc () {
 pipeutil = cocoon.createObject(;
 return { dom: pipeutil.processToDOM(/getuser) }

Where the pipeline util allready exists since a year or so.

Thats what I'm going to focus on. I'm certain that there are good 
reasons for other solutions, but IMO we should focus on having one 
_excelent_ way of doing things rather than a couple of ok and 
independently developed, ways following different paradigms and focusing 
on different use cases and diffusing the development effort. But thats 
just me, do what you want.


View raw message