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



Reply via email to