cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: Initial version of spring-app block
Date Sun, 24 Apr 2005 17:48:55 GMT
Rolf Kulemann wrote:
> first: I really appreciate work towards Spring integration into Cocoon.
> Unfortunately I'm a old Cocoon 2.1.x guy and I do not know Cocoon 2.2
> very good. However, I'm using Spring and Cocoon 2.1.x heavily and want
> to tell you some of my thoughts. 
> I looked at the example you (Carsten) provided in the spring-app block.
> The flow.js is as follows:
> <snip/>
> What I don't like in my Spring/Cocoon apps (which is also the problem here) is:
> Spring is great in dependency injection and I want to avoid obtaining components
> direct via any component manager.
> So, a short idea to solve this could be to extend the flow declaration in the sitemap:
> <map:flow language="javascript">
>     <map:script src="flow.js">
>        <property name="myBean"><ref bean="spring-test"/></property>
>     </map>
> </map:flow>
> MyBean is than automatically "injected" into the flow context so that i can simply 
> write sth. like
> function test() {
>   myBean.getAProperty();
> }
> This is not only related to flow and Spring but to flow use and dep. injection in 
> general doesn't matter what container is used.
> Now, I will go and play with Cocoon 2.2 and Spring a bit. Thanks Carsten, nice work.
Thanks. Hmm, your idea reminds me a little bit of our unified object
model discussion. We discussed some time ago to open up the object model
of Cocoon, so users can add their own "accessors" (or whatever you call
them). Currently in flow you have access to the request object, to the
parameters object etc. With own accessors you have access to some
configured objects, so you can write:
cocoon.myAccessor.something() in flow and configure your accessor
"somewhere" (perhaps cocoon.xconf) as an extension to the object model.
The advantage then would be that you could also use this in other parts
of cocoon, like the sitemap or jxtg etc.
So, this is similar to your idea apart from a) a different configuration
location and b) a slightly different part (you have to access everything
via the cocoon object).
Would that mechanism make you happy?

Apart from that, I'm not sure if your approach might be too much magic.
If you write your flow script you have to know which beans/components
are configured in the sitemap using what names etc. That's not directly
visible in the flow script.

Another approach would be to use intercepted flow script (don't know the
state yet, there is something in the scratchpad). Using this you add
functions that are run before a flow script function is called. So, you
define a variable myBean in this aspect and do a lookup of the
component/bean. As this snippet is called before your own flow function,
you can simply access myBean. Again it's a little bit different from
your approach.

What do you think?


Carsten Ziegeler - Open Source Group, S&N AG

View raw message