cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] Access to the object model
Date Fri, 23 May 2003 04:57:31 GMT
[avoid snipping on purpose to keep full context]

on 5/22/03 3:44 AM Sylvain Wallez wrote:

> 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.

Agreed. IoC is kept that way.

>>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. 

Yes, this is the issue.

> 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.

I tend to agree with this. Flow is overkill for a single few lines of
stateless glue.

> 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 ;-)

Ok, I stand corrected and I change my -1 to a +1 for a context-based
reference to the cocoon object model of general avalon components when
loaded by cocoon.


View raw message