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

--
Carsten Ziegeler
[EMAIL PROTECTED]

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to