cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: getComponent vs. context.getAttribute
Date Wed, 12 Mar 2008 10:24:56 GMT
Patrick Heiden wrote:
> Hi,
>>> Is there any notable difference in asking for Spring-beans inside
>> flow-scripts wheter using
>>> cocoon.getComponent("myBean"); // via avalon-bridge!?
>>> or
>>> var appCtx =
>> cocoon.context.getAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE);
>>> appCtx.getBean("myBean");
>>> ??
>> Yes, there is a difference :) The first one does not use the avalon 
>> bridge but uses the context of the current sitemap. This might be a sub 
>> context of the root web application context with additional/different
>> beans.
>> So, getComponent() is still the way to go :)
> Thanks for this one! It might even be the simpler approach. What is confusing for me
so far (informations I got from Grzegorz Kossakowski), that the actual implementation (2.2)
does not 'really' support different bean-containers. I am able to define beans within blocks
A context (META-INF/cocoon/spring/*.xml) and they are visible to other blocks of my webapp
as well. How does the future look like for this and how should actual design/configuration
of beans (e.g. a service-layer) be done to be prepared?
There are different approaches; one of them is the new block concept 
(which Grzegorz is refering to) and that does not support a hierarchy of 
containers - but I'm not an expert for blocks, so I have no idea what 
has been done/will be planned for that.

The other approach is the 2.1.x compatible approach: by creating a 
hierarchy of sitemaps (using map:mount) you create a hierarchy of 
containers (like it was in 2.1.x). It is possible to define beans on er 
per sitemap base. However, it seems that current development of Cocoon 
favours the blocks concept.


Carsten Ziegeler

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

View raw message