cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rolf Kulemann <r...@apache.org>
Subject Re: Initial version of spring-app block
Date Sun, 24 Apr 2005 22:09:07 GMT
On Sun, 2005-04-24 at 19:48, Carsten Ziegeler wrote:
> Rolf Kulemann wrote:

...

> > 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.
> > 

...

NOTE: I found out that the <application-container> was setup using the
configuration from <components>. That prevented e.g. to use 

<application-container>
   <myparam>value</myparam>
<application-container>

myparam could not be detremined in the configure method of the compoenent. I fixed that in
trunk. I hope that was ok.

> 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.

Mmmh, would be an option, but I do not like to configure things in cocoon.xconf since it is
too static imho. 
On sitemap level that would be more appropriate.


> The advantage then would be that you could also use this in other parts
> of cocoon, like the sitemap or jxtg etc.

Well, if we follow my alternative idea from above, would it still be possible to use that
in jxtg ?
Mhh, and looking at my various CForms apps: I do not like put pass all the beans I need in
a JXTemplate
via the cocoon.sendPage("", {...}) thing. I would like to do that on a more declarative way
like you do it in struts
or JSF (well Struts...) but that is too static, since I is the declaration is evaluated on
servlet startup.

So, the picture I have to declare somewhere, which beans must be available for lets say a
form processing in flow and templates.

> 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?

Accessing via the cocoon object woulk be ok, but cocoon.xconf is not 100%.

> 
> 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.

Mhh, I guess this is the problem of being type free. In Spring the dep. injection works via
properties.
If I transfer that to flow, I would need to write

------
var myBean;

function thisAndThat() {
	myBean.doIt();
}
-----
where myBean is injected. But you are right. Another problem are changing bean names. 
If I  have them in a single file or two like in a sitemap, the changes would be easier to
adopt.

> 
> 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.

Mhh, nice idea, but that partions all the flow thingy too much for my problem.

> 
> What do you think?

See above and thanks for your answers.

(My first mail went out too early :)

-- 
Rolf Kulemann


Mime
View raw message