Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
To: cocoon-dev@xml.apache.org
From: Stefano Mazzocchi <stefano@apache.org>
Subject: Re: SoC between flow and sitemap
Date: Fri, 16 May 2003 20:03:53 -0500
Lines: 169
Message-ID: <ba41ln$v68$1@main.gmane.org>
References: <3EC498D1.7000807@outerthought.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
 rv:1.3.1) Gecko/20030425
In-Reply-To: <3EC498D1.7000807@outerthought.org>
Sender: news <news@main.gmane.org>

on 5/16/03 2:52 AM Marc Portier wrote:

> Please understand: I _do_ like flow (how could we not) there just 
> seem to be some unclear contracts between flow and sitemap in my 
> head.... (so excuse me for the maybe rant-y tone of voice here)

no problem. The more we sort those things out before we release, the better.

> I hope to be fueling some discusion that might lead to clarifying 
> some of the contracts usefull for general web-app-development 
> inside cocoon (even for those not using flow maybe).. it could be 
> that I just overlooked some ready excisting facts of life, please 
> point those out then
> 
> 
> [1] flow communicates with pipeline components behind the scenes.
> (Actually it's not the only component doing so, but that should 
> not be seen as a justification)
> 
> sendpageandwait() sets two important objects as attributes to the 
> request attribute... (the continuation and the so called 
> bean-dict (hashmap-like 2nd argument to the function)
> 
> these get picked up by jxpathtransformer (or generator) or any 
> other pipeline-component that wants to use that information.
> 
> And there is my fundamental itch with this approach: those 
> pipeline-components are to be written to deal (exclusively) with 
> the quite arbitrarily manner in which these 'beans' or usefull 
> objects are communicated between the deciding logic (flowscipt) 
> and the consuming publication pipe components

Yes, this 'weak contract' is a known problem. The way the flow
communicates with sitemap components is underfined.

In the past, Carsten expressed the need to avoid adding flow-specific
hooks into the cocoon object model. Carsten, do you still feel that way
about it?

I know you dislike flowscript and would like to be able to deploy your
stuff without it, but this is forcing such an important internal module
to be based on such a weak contract and many (myself included) dislike
this very much.

Besides, if you don't use flowscript tags into your sitemap, the classes
are not even loaded by the treeprocessor, so you can deploy your
machinery without even shipping rhino and things would work anyway.

I would suggest we add a Flow object to the object model.

> While it's a perfect Model2 approach I would argue that we do NOT 
> want to keep these arbitrary choices (why the request object? why 
> the chosen attribute names?) hidden in the java implementation 
> source codes, yet rather have it under the control of the sitemap 
> editor.

Uh?

> <map:match pattern="...">
>    <map:call function="..">
>      <!--+
>          | Can we (euh, do we want to) come up with some
>          | mapping in here between
>          |  - logical names of important objects produced
>          |      inside (by) the flow script: 'continuation',
>          |      'bean-dict', but also script specific stuff like
>          |      'user-preferences', 'chat-room',...
>          |  - and some arbitrary object-addressing-string that
>          |      allows to formally describe in which space
>          |      (session, application, request) and under which
>          |      attributename that 'logical' object is to be
>          |      stored/retrieved
>          +-->
>    </map:call>
> </map:match>

ah, you want the sitemap to be able to indicate the mapping between the
flow parameters and the object model?

I don't like it. I think it would be much more separate to provide a
Flow object in the object model and let the components take care of it.

components that interoperate with the flow known about it anyway so that
can load the right object and play with it with no need to
flow->object_model translation dictated by the sitemap.

> I would find it logic then that those so called 
> object-addressing-strings (they should be quite url-like) get 
> reused to guide the pipeline-components to where they might find 
> additional information.

I really don't see the need for this sitemap dictated mapping. Rather
the opposite: it is complex and doesn't change the picture at all.

> [2] flow decides on pipelines outside the sitemap-control.
> 
> sendPageAndWait()'s first argument points to the cocoon 
> publication line to use in any given instance.
> 
> If I would compare this to Actions it would pretty much be the 
> action that decides on the redirect to use rather then returning 
> a map that contains enough state-information that allows the 
> sitemap (with the use of more matchers, selectors and/or smart 
> resources) to put the correct pipeline to work.
> 
> Making this comparison

oh, did I ever mention that my FS-alarms get activated when I smell
symmetry-driven design?

> I'm in fact questioning if we wouldn't 
> rather put that part of binding the flow-state back to the 
> uri-request-space under control of the sitemap (the one in charge 
> of the pipes and their matching URI's in the first place?)

I don't get it: in the flow, you have the ability to assemble the URI
you are calling as you like, then in the sitemap, you process it. There
is no redirection, just invocation.

And you are passing *both* URI and a map, but the URI goes to the
sitemap and the map goes to the pipeline, actually separating concerns
that, in actions, were mixed.

Following actions as paradigms is going backwards in SoC design as flow
allows *better* SoC.

[...]

> So, It's not because the js-script and sitemap.xmap are different 
> files that they shouldn't be under control of the same person... 
> (which it nowadays needs to be as I tried to argument)

I've been working alone on my last two flowscript based cocoon webapps
and I can tell you that I *enjoyed* having separate files where

 - one declaratively indicates the the pipelines
 - the other indicates the transition between them and feeds data to
them based on some external business logic.

The first parameter of sendPage* is *NOT* a URL, a real locator, but a
*URI* a name of the pipeline you wish to be called. Why? because the URL
of the browser is *NOT* influenced by the URI that you indicate in that
call (unlike in client-side redirects!)

I really see no reasons to change this behavior.

> However, in this case I think there is a future for a more 
> ready-made reuse and even distribution of flowscipts that can be 
> hookep up in different existing cocoon webapps that each need to 
> fit it into their own uri-request-space, hopefully without the 
> need to change the script that is.

blocks will address this with the use of the block: protocol. Basically

 sendPageAndWait("block:role://pipeline",{});

will look up in the block deployment manager what block is associated
with the given "role" in this particular context and route the request
to the sitemap that controls that block URI space, which will match the
/pipeline request it receives.

> regards, and upfront thx for your thoughts, counter-arguments and 
> possible useful best practices on these

You are welcome.

-- 
Stefano.