cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ricardo Rocha <>
Subject Re: [RT] Access to the object model
Date Fri, 23 May 2003 15:31:44 GMT
Sylvain Wallez wrote:
> Ricardo Rocha wrote:
>> 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.

Yes, I see your point.

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

By making the object model part of the context the component is not
made dependend on it. Both SoC and IoC are preserved, yes.

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

Definitely so, thanks Sylvain!

View raw message