cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: Accessors (was Re: Adding cocoon.suicide() to the FOM API.)
Date Thu, 17 Mar 2005 20:41:50 GMT
Ralph Goers wrote:
> Daniel Fagerstrom wrote:
>> Ralph Goers wrote:
>>> 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.

Like FOM which in turn is modeled after the browser object model in web 
browsers. Part of the idea IIRC was that it should be natural to used 
for people who had used JS in browsers.

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

It data oriented rather than object oriented. If that is good or bad 
depends on your perspective. For accessing the kind of data that we have 
in FOM it is OK for me. So I guess that you have to list some of your 
agruments anyway if you want me to understand why its awful.

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

Ok, if your webapps contains a lot of custom Java code I can understand 
that the Avalon way can be frustrating. The webapps that we build where 
I work contains very small amounts of custom Java code. For us having 
things configurable is an advantage rather than the opposite.

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

I don't know, IOC component managers where IIUC invented because some 
people had bad experiences with the scalability for direct object 
access. I have used that paradigm for so long that I don't remember what 
problems I might have had before ;) But I think Cocoon is easier to use 
and maintain if we follow the same design patterns everywhere.

Don't you think some of the problems that you describe above becomes 
smaller if we introduce the possibility to use modern containers like 
Spring and Hivemind in application code, like Carsten proposed?

I don't see the accessors as a general way to integrate business objects 
in Cocoon but just as a evolution of the input/output module concept 
that is better adapted to the needs in templates and flow and not only 
to the needs for the sitemap.

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

How does the template know in what package to find the Request object? 
And how does it know if it should use the http or command line variant?

I get the feeling that one have to rebuild quite a lot of the 
architecture that we already have from Avalon if we follow the 
X.getInstance() way.

> Is that clearer?

It is. But to me it seem like we are attacking different problem areas, 
and I'm not certain that they should be solved with the same tool.


View raw message