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.

WDYT?

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

Attachment: smime.p7s
Description: S/MIME cryptographic signature



Reply via email to