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]
