cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [VOTE] Unrestricting the FOM
Date Tue, 15 Jun 2004 16:57:03 GMT
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. Currently these attributes are not really used.

That's what I pointed out above: the Cocoon core currently makes no use 
of attributes in env-context, session and request. These are for 
application use, and up to now the Cocoon core has not "polluted" these 

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

Yep. Let's list what's in avalon-context.

The main DefaultContext is initialized with:
- Constants.CONTEXT_ENVIRONMENT_CONTEXT : the environment context (type 
- Constants.CONTEXT_WORK_DIR : Cocoon's work directory (type File)
- ContextHelper.CONTEXT_ROOT_URL : the servlet context's URL (type 
String - why not URL?)
- Constants.CONTEXT_UPLOAD_DIR : the upload directory (type File)
- Constants.CONTEXT_CACHE_DIR : the cache directory (type File)
- Constants.CONTEXT_CONFIG_URL : location of cocoon.xconf (type URL, 
used only to initialize the Cocoon object)
- Constants.CONTEXT_DEFAULT_ENCODING : default form encoding (type String)
- Constants.CONTEXT_CLASS_LOADER : CocoonServlet's classloader (type 
ClassLoader, used only to initialize the Cocoon object)
- Constants.CONTEXT_CLASSPATH : the classpath used by the XSP engine 
(type String)

The actual Context seen by applications is a ComponentContext that wraps 
the above DefaultContext with:
- ContextHelper.CONTEXT_OBJECT_MODEL : the current object model (type Map)
- ContextHelper.CONTEXT_SITEMAP_SERVICE_MANAGER : the current sitemap's 
service manager
- ComponentContext.OBJECT_MODEL_KEY_PREFIX : prefix to access members of 
the object model (could be removed, as only used in the implementation 
of ContextHelper.getRequest()/getResponse())

When in HTTP environment, there's also:
- CocoonServlet.CONTEXT_SERVLET_CONFIG : the ServletConfig

When in portlet environment, there's also
- CocoonPortlet.CONTEXT_PORTLET_CONFIG: the PortletConfig

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

Makes sense. And migrating some stuff to the env-context may help 
removing some dependencies on Avalon. But whe have to be very careful 
about what attributes we want to move from avalon-context to 
env-context, and be sure they will still make sense in a new container 
and within blocks.

>So, why not combining those somehow. Currently you get the o.a.c.e.Context from the avalon
>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).

The only point I'm not sure about is the object model: should it be in 
the env-context, since it also contains that env-context? Kind of 
circular dependency that may be confusing...

What we need actually is some kind of mini-environment that would give 
access only to the "safe" properties of o.a.c.e.Environment, i.e. mainly 
the object model and attributes, plus access to the current 
avalon-context attributes through type-safe getter methods.

>Then in flow, cocoon.context works perfect.

Yupp. <rt>And with an IOC type2/3 container we could even totally remove 
the dependency on avalon-context by simply have a 
setContext(o.a.c.e.Context) method ;-)</rt>


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message