Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <4239B837.4030301@dslextreme.com>
Date: Thu, 17 Mar 2005 09:02:47 -0800
From: Ralph Goers <Ralph.Goers@dslextreme.com>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Accessors (was Re: Adding cocoon.suicide() to the FOM API.)
References: <4231A8CF.6040001@apache.org>
 <5e6d40c558bc779677ba649e7e42f13e@apache.org> <4231B695.8040406@apache.org>
 <4231B9E1.6020803@nada.kth.se> <4231BD43.7070208@apache.org>
 <4231BFB9.9010304@nada.kth.se> <4231C89B.8090202@apache.org>
 <4231D20A.5010603@dslextreme.com> <4237F3A4.4030908@nada.kth.se>
In-Reply-To: <4237F3A4.4030908@nada.kth.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Daniel Fagerstrom wrote:

> Ralph Goers wrote:
>
>> Sylvain Wallez wrote:
>>
>>> Oh yes, sure. I totally agree with the concept. It's not a factory 
>>> and it's not an object holder as depending on the implementation it 
>>> can be either or even something else. So accessor is fine!
>>
>> Did this accessor thing evolve from another discussion?  It seemed to 
>> pop up out of thin air in this thread.
>
> It did, I had thought a little bit more about what to call them and 
> wanted to tell, Sylvain decreased the confussion by changing the 
> thread name.
>
>> Is this what I hope it means?  If it is, then I hope to see classes 
>> like Request, Session, Context, etc. be modified to implement the 
>> interface.  To me, this would mean that they implement a static get 
>> method that returns the appropriate instance of the object.  Perhaps 
>> a better name for this would be Accessible.  I guess your plan is to 
>> implement a separate Accessor class to do this instead?
>
>
> I'm not geting what your aim at, could you tell a little bit about how 
> you want to use the accessores so that I can understand why you prefer 
> such a solution compared to the component based approach that we have 
> discussed.

Actually, a couple approaches have been mentioned.  As I understand 
them, they are:
1.   Have a global "component object model" that everything is anchored 
in and accessed through.  Frankly, I see this as a bad idea that needs 
to go away - at least the accessing part.  There are so many reasons why 
this is awful that I don't even want to start listing them. But just for 
a start, it is hardly object oriented as it makes the component object 
model have to know way too much.
2.  Have an Accessor interface, presumably with a class that implements 
it for each type of object to be accessed, such as RequestAccessor, 
SessionAccessor, etc.  In and of itself, this isn't a bad idea.  It just 
isn't necessary, in my opinion.

When I was working on my last portal enhancements, I was frustrated that 
I couldn't get ahold of some of the objects I needed.  The "right way" 
would have required that I make some of the classes implement Avalon 
interfaces which, of course, meant adding more definitions to 
cocoon.xconf.  This is frustrating when all you want is to the reference 
to some other object, but to get it you have to have a Context or a 
service manager.  It would be much more convenient for a lot of objects, 
as well as many flow applications, to be able to just do:
    Object.getInstance();

This places the burden for locating the correct object instance on the 
object itself which, in my opinion, is where it belongs.  It also allows 
the object to use any number of techniques to locate the correct 
instance; it can retrieve it from the object model, from the component 
manager, or whatever.  Furthermore, it allows one to write something 
like ${Request} in a template or flowscript and have that be replaced 
with a reference to the correct object instance.

Is that clearer?

Ralph