cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject RE: SoC between flow and sitemap
Date Sun, 18 May 2003 10:44:15 GMT
Stefano Mazzocchi wrote:
> 
> 
> > 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.
> 
Putting it simple: I changed my mind - I think flow is very, very 
useful and should belong to the core. Now, I didn't had time to catch
up on the flow stuff and the object model etc. and I was thinking
in the last days how to integrate flow much better into the
pipeline execution, so basically to address the problem from above.

Now, I always liked continuations but I didn't like javascript and
the scripting approach. But I changed my mind on the second one,
although you have to take care about what you do in javascript.
So, flow the number one feature for building web applications
and in combination with the cocoon pipelining you have a platform
that beats everything else on earth (at least for me).

> SNIP
>
> 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.
>
Yes.
 
> SNIP
> > 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.
> 
To be honest, the first time I saw flow I didn't like the separation
either. I always thought that I want to use flow directly in the sitemap.
But now I agree with Stefano (and all the others), that separating these
things is much better.

What I currently don't like that much (but it's ok for now), is that
you have to define the hooks for the flow in the sitemap. So you have
to match the incomming request and call the flow from the sitemap.
And then you call the pipeline from the flow. I'm thinking about
directly invoking the flow (if a contination is available perhaps)
and not querying the sitemap first.

So, a big +1 for flow :)

Carsten

Mime
View raw message