cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
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:
>  
>
<snip/>

>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>
>  ...
></map:>
>
>The same example could be done in sitemap+flow, but look how !
>
>sitemap.xmap
>-------------------
><flow language="javascript">
>  <script src="myfunc.js"/>
></map:flow>
>
><pipeline match="begin">
> <call function="myfunc">
></pipeline>
>
><pipeline match="returntositemap">
>  <generate type="jx" src="..."/>
>  ...
></pipeline>
>
>myfunc.js
>--------------
>function myfunc () {
> uri = "cocoon:/getuser";
> parser =
>cocoon.getComponent(Packages.org.apache.excalibur.xml.dom.DOMParser.ROLE);
>        resolver =
>cocoon.getComponent(Packages.org.apache.cocoon.environment.SourceResolver.ROLE);
>        source = resolver.resolveURI(uri);
>        var is = new
>Packages.org.xml.sax.InputSource(source.getInputStream());
>        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:

sitemap.xmap
-------------------
<flow language="javascript">
  <script src="myfunc.js"/>
</map:flow>

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

myfunc.js
--------------
function myfunc () {
 pipeutil = cocoon.createObject(Packages.org.apache.cocoon.components.flow.util.PipelineUtil);
 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.

/Daniel


Mime
View raw message