Thorsten Scherler pisze:
>> It introduces a dependency on very specific implementation that may change
>> in the future.
>
> That is true. Like I wrote in the first mail, would be awesome to have
> cocoon.spring.getBean('NameOfBean').
Personally, I don't like this kind of solution as well because I think one
should follow push
approach instead of pull approach when it comes to access to the data from
template. I think the
best is to make available to ObjectModel (thus to expressions and templates)
what is really needed.
If different blocks need different things that you don't know in advance then
implement different
ObjectModelProviders for each block. Maintenance cost of such solution is much
lower.
>> Thorsten and Roy, if you really need to access some beans from expressions I
>> suggest to add them to
>> ObjectModel by implementing ObjectModelProvider interface.
>
> Hmm, is there any documentation about how to this. I mean how can I
> create a cocoon.spring.getBean('NameOfBean') factory?
No but the whole concept is so easy that I can explain it within a few words
here.
Take a look at existing implementation of ObjectModelProvider[1] for 'cocoon'
object[2][3]. The
ObjectModelProvider is a bean implementing a very simple interface. The name
convention of that bean is:
org.apache.cocoon.el.objectmodel.ObjectModelProvider/[the-name-of-the-variable]
So if you implement your own ObjectModelProvider and name bean with:
org.apache.cocoon.el.objectmodel.ObjectModelProvider/spring
You will be able to access it from top level using "spring" variable. The
object returned by
provider might be anything you like. It might be a simple map, dynamic map
listing all beans or just
a custom class with custom method that will do whatever you want.
You don't need to register ObjectModelProvider in any way. Following naming
convention is enough.
>> This way you can easily control what
>> exactly the template can access and you remove dependency on specific
>> implementation.
>
> IMO a template should be able to access all beans from cocoon. If we
> want to limit the access one can think about adding security to
> cocoon.spring.getBean('NameOfBean') which checks whether the template is
> allow to access the bean. Wee bit like using
> http://www.acegisecurity.org/ for that part.
That might be another approach to tackle problems with security. Anyway, while
writing my original
comment I was having in mind more design problems and simple separation of
concerns. Template should
be able to access what it really needs and nothing more.
[1]
http://cocoon.apache.org/2.2/core-modules/expression-language-api/1.0/apidocs/org/apache/cocoon/el/objectmodel/ObjectModelProvider.html
[2]
http://svn.eu.apache.org/viewvc/cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/java/org/apache/cocoon/objectmodel/impl/CocoonEntryObjectModelProvider.java?revision=636423&view=markup
[3]
http://svn.eu.apache.org/viewvc/cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/resources/META-INF/cocoon/spring/CocoonEntryObjectModelProvider.xml?view=markup
--
Grzegorz Kossakowski
