cocoon-dev mailing list archives

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

>>Ok. So what about turning on the ability to pass dom inside sitemap
>>parameters ?
>>1) pipeline more clear
>><generate type="jx" src="..">
>>  <parameter name="auth" dom="{session-context:authentication}"/>
> I don't get why you are so obsessed with being able to do everything
> from the sitemap. Once, when the community started to develop Cocoon in
> a direction to better support webapps there was the question if we
> should put more abilities to have control stuff in the pipeline or if
> this should be done in a separate system, the flowscript. Had we chosen
> the sitemap way we would have need to put more mechanisms in the sitemap
> to preserve nice SOC. That was the way I prefered back then.

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}"/>

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;
        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 don't see any good reasons why the sitemap is apprently excluded from
serious discussion with jx (pipeline had side and central roles in the
workflow, see my previous msgs). Why flow is the only one who can pass some
object to jx ?

If you return to my previous example, it could be usefull for flow too (side

<pipeline match="begin">
  <call function="myfunc">
    <parameter name="dom" dom="{cocoon:/getuser}"/>

function myfunc () {
 /* workflow that involves several SendPage */
 /* no more access the servicemanager just for to retrieving a dom
    that can be passed by sitemap via inputmodule:
    simplicity & reusability */
 $cocoon.sendPage("returntositemap", $cocoon.parameters.dom)

> Now we have gone the flowscript way and I'm completely happy with that.
> There are nummerous good reasons for that decision and some good reason
> against it. But in some way that doesn't matter anymore. What is much
> more important is that we focus our energy on making Cocoon realy smooth
> and efficient to use along the choosen direction. Trying to support
> several similar ways of achieving the same things only disolve our energy.
> Whats important to notice for software development is that if enough
> talented people choose an at least somewhat reasonable direction and
> focus on, it _makes_ the direction a good direction after a while. To be
> worthwhile to backtrack and chose another direction must lead to very
> large advantages to be anything else but destructive.

Just pointed out that if you want to respect IoC and SoC, remove all sides
effects from jx, and keep it the simpliest possible (as far as i could
understood), the proposed solution would achieve all that goals. The actual
design break in several points.

> Conclusion: the current direction is that objects and control are
> handled in flowscript rather than pipelines. Let us focus on making that
> smooth rather than confusing our users and ourselves about where things
> should be done.

As long as the sitemap controler is a controler (MVC), and i don't use the
pipeline nor jx for workflow, i really don't see the point.

>>2) servicemanager, $request, $session useless in jx (pass parameters
>>explicitly in the sitemap like you use to do with SendPage in flow). SoC
>>3) inversion of control not broken. (Exception triggered from the
>>sitemap). You can remove java object access from jx since they are used
>>for breaking this IoC and SoC.
> Ok, you have removed the "programming" from JXTG and put it in the
> sitemap instead, whats the gain?

Absolutely no. I only proposed to remove direct access to OM because you can
pass directly (dom or bean) parameters from the sitemap. No more side
effects possible, and you know that your designers will never be able to
set something in session (very weird for a language which is said to be
devoted to templating only ? no ?). You enhance your vision (from the
sitemap point of view) of the process since you know that if you don't pass
the $session to the template, you just can't use it (ie don't use it).

Sorry but i see only benefits  (user point of view).

> No thanks ;)

Perhaps asking to other people ?



View raw message