cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [RT] Access to the object model
Date Thu, 22 May 2003 08:44:38 GMT
Ricardo Rocha wrote:

> Stefano Mazzocchi wrote:
> > Now, my question remains: the flow has access to the object model and
> > the flow has access to the component, why don't you use that as the
> > glue between them and leave IoC intact?
> > What am I missing?
> Sylvain Wallez wrote:
> > In this use case, flow is of no use in the publication part of the
> > application, which are just straight pipelines. Or do you mean that a
> > script could be used to prepare some sitemap variables ? This seems
> > overkill to me when a simple and more readable declarative approach
> > can do the job.
> I believe the flow is of use in any situation where controlling logic 
> is required.

We first have to define what "controlling logic" is. We have lived for 
years without the flow, and were very happy without it for publication 
purposes. It's need really appeared with web applications requiring a 
lot of state and flow management. And this is for the flow that flow 
script (as its names implies) makes sense. I find it overcomplex to have 
to write a JavaScript function just to build a hashmap for later use by 
the view when a simple declarative approach in the sitemap and/or the 
xconf file does the job.

> What I personaly find overkill is giving _all_ components access to 
> the object model (and breaking IoC in the process). 

I disagree here : IMO, widening the access to the object model has 
nothing to do with IoC. Maybe SoC (see below), but not IoC. We would 
break IoC if we allowed access to the object model from everywhere like 
what the CocoonComponentManager hack allows today. If the object model 
is accessible though the Avalon context, then IoC is kept, since the 
component _is given_ the object model in a container-controlled manner.

> I tend to think of the flow as a glue between distributed layers and 
> component spaces. That's why I like the fact it's implemented in a 
> scripting language.
> Non-sitemap components shouldn't have access to the object model.
> If, for example, a repository manager needs to be told under what 
> directory to store some content and such information happens to be 
> stored in the session object, what do we do? Have the _repository 
> manager_ mess with Cocoon's object model directly so that it can pick 
> the location?? C'mon! That would break both IoC *and* SoC.

As said above, accessing the object model through the Avalon context is 
IMO clean IoC. It's just an additional data added *by the container* to 
the working context of components.

Now about SoC. I my use case, the repository manager actually doesn't 
need access to the object model : it uses an expression that may include 
input-module calls, and _some_ of these input modules may require access 
to the object model because this is where they get their data from (e.g. 
"session-attr"). So what the repository needs is a way to resolve these 
expressions, whatever their content is.

The current implementation of the repository does need the object model 
since the input module interface needs it (even if the actual module 
used doesn't actually use it). But if input modules that need the object 
model were able to access it through their context, then the repository 
would not even care about the existence of the object model.

And this leads IMO to greater reusability and SoC : this would allow the 
InputModule interface to be independent of Cocoon. Only _some_ 
Cocoon-related implementations would require access to the object model. 
And the repository would only have a dependency on the InputModule 
interface, but would not care about object model (as it doesn't have to).

> If a non-sitemap components needs access to data stored in Cocoon's 
> object model then the right thing to do (tm) is to have the controller 
> decode/extract/build such data and make it available to the component 
> in a Cocoon-agnostic fashion. By "controller" I mean either the flow 
> or sitemap-level request decoding.

What you're describing here can be defined as yet another entry in the 
Context, whose value would be set by the controller. But then again, I 
find it overkill to have to go trough some flow script when there is no 
flow but only data access.

This is a pure push approach and (I already stated this some time ago), 
I don't believe in pure push solutions, which impose all data to be 
gathered in a single location. The bad side effects of this single 
location is that everybody will add its stuff in it (management issue), 
and at the end, we don't know which of the data pushed are actually 
used, and we keep them "just in case" (performance and memory issue).

On this subject, I've read yesterday an interesting post about the slow 
death of XMLC (see [1]) which is a pure push dynamic page framework. 3 
years ago, I studied XMLC and one of the first points that made me trash 
it was this push-only model. I discovered Cocoon a few days later, and 
I'm still there ;-)

> I may be missing something big here so (please!) enlighten me if 
> that's the case. 

Hope the above gives some food for thought !


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message