cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Quinn <>
Subject Re: [VOTE] Unrestricting the FOM
Date Tue, 15 Jun 2004 16:37:01 GMT

On 15 Jun 2004, at 15:57, Carsten Ziegeler wrote:

> Sylvain Wallez wrote:
>>> We already have cocoon.context, couldn't we make things
>> available from there?
>> Mmmh... don't know if it's a good idea, as the Cocoon core
>> currently doesn't rely on custom attributes in the
>> environment objects (unless I'm mistaken). This would
>> complexify things a bit, IMO.
> Hmm, ok we currently have a o.a.c.environment.Context which
> has some functions from the servlet context object and attributes.

This is where I would have expected to find "work-directory", being a 
Servlet-supplied parameter.

> Currently these attributes are not really used.

Ah, I though these were the context attributes you could access from 
FlowScript, as in:
	cocoon.context.setAttribute ("name", myObject);
I have used this before ..... when I needed to share the same object 
between several users.

> And we have o.a.a.context.Context which is a map containing
> many important information about the application.

Do you mean org.apache.avalon.framework.context.Context ?

> For me it seems that two contexts is one too much :)

+ 1

It is rather complicated ;)

> So, why not combining those somehow. Currently you get the
> o.a.c.e.Context from the avalon context.
> Now, we could for example store all information we currently
> have in the avalon context into the environment context
> and using the environment context as the only reference
> for application information. If you need this context
> you can get it from the avalon context. The avalon context
> only contains this single piece of information (of course
> for compatibility we let everything remain there as
> well).
> Then in flow, cocoon.context works perfect.

YES !!!

Should I hold back on committing my changes to make ContextHelper 
Contextualizable, to wait to see what comes out of this proposal ?

BTW. I think there may be a related issue here with a problem noted a 
while ago, where it was not possible to read parameters setup in 
web.xml as expected using :

	org.apache.cocoon.environment.Context.getInitParameter(String name)

Unless Cocoon was 'expecting' that parameter to be there.

I don't know if this is a bug or a just a misunderstanding ;)

regards Jeremy

                   If email from this address is not signed
                                 IT IS NOT FROM ME

                         Always check the label, folks !!!!!

View raw message