cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From giacomo <>
Subject Re: AW: Restricting objectModel
Date Fri, 18 May 2001 09:57:02 GMT

On Fri, 18 May 2001, Carsten Ziegeler wrote:

> > Giacomo Pati wrote:
> >
> > Dead developpers
> >
> > A recent question on the user list "how can I put my own stuff into the
> > objectModel" forced me to rethink about the the concept of the
> > objectModel.
> >
> > Let me resume: The Cocoon core engine doesn't really care about the
> > environment it runs in. Thus we introduced the notion of an abstract
> > Environment with the absolute minimum of functionality needed
> > exclusively by the Cocoon engine to be able to work. To have a contract
> > between a concrete Environment and the sitemap components, which are BTW
> > the only component which need to know about the conrete Environment they
> > run in, we introduced the objectModel as a container for important
> > environmental objects. The concrete servlet Environment implemented
> > today uses the objectModel to put in the Request, Response and Context
> > objects of the servlet environment. This enables the Cocoon engine to
> > operate in almost any environment (ie. Apache James [SMTP] or an EJB
> > container) by simply creating an concrete Environment class.
> >
> > Now, I'd like to change the type of the objectModel from a Map to an
> > Avalon Context. This will downgrade it to an read-only object preventing
> > users from putting their own stuff in it.
> >
> > If nobody gives me a reasonable -1 I'd volunteer to change it the way
> > I've proposed.
> >
> So here it is:
> -1
> The objectModel is the central object which is passed to nearly all
> components (except serializers). Besides the sax events it is the
> only possibility to pass any information from one component to another.
> For example an action can enhance the objectModel by putting important
> information in it which is retrieved by some other components (perhaps
> again an action).
> If we would use an avalon context there is no possibility to share
> information between those components.

Don't you think that attributes of the session and request objects are
more suitable for your approach (aren't they made for that purpose)?
They are also passed to all components so your argument is not really
convincing me. The objectModel was never meant to be a placeholder for
application specific objects.

Can I read in between your lines that you already us it that way?


To unsubscribe, e-mail:
For additional commands, email:

View raw message