cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Reinhard Poetz" <reinh...@apache.org>
Subject RE: Introducing IOC for Java classes created in flowscript
Date Thu, 20 Nov 2003 17:59:13 GMT

From: Sylvain Wallez 

> Reinhard Poetz wrote:
> 
> >From: Sylvain Wallez
> >  
> >
> >>Hi all,
> >>
> >>Flowscript currently gives two means to use Java classes: use 
> >>components (cocoon.getComponent()) or simply create a Java 
> object and use it (new MyClass()). As it's not very 
> convenient to create a new component and install it in 
> cocoon.xconf just to call Java code from the flow, the second 
> solution is often used.
> >>    
> >>
> >
> >yep, unfortunatly ...
> >  
> >
> 
> I don't agree with this "unfortunately": writing and installing a 
> component is not an easy task for a newbie, and if it's the only 
> solution we provide for calling Java code from flowscript, many will 
> turn around and go away.

sorry, my "unfortunatly" was a bit misleading. I agree with you
completly in this point!

> 
> As said Alan Kay: "Simple things should be simple, complex 
> things should 
> be possible"!

:-)

> 
> >>But a problem comes when these Java objects need to access e.g. 
> >>request parameters, session attributes, components, etc: 
> the only way 
> >>is to pass them the "cocoon" object that provides this access.
> >>
> >>But "cocoon" is of class "FOM_Cocoon" which is very specific to the 
> >>internals of flowscript and linking code to this specific 
> class isn't IMO a good thing to do. Furthermore, accessing 
> elements of the object model through getters isn't consistent 
> with the way it's usually done in other Cocoon code and violates IOC.
> >>    
> >>
> >
> >yep. when I startet to add interception capabilities to flowscript I 
> >had to copy the existing FOM_Cocoon because it had direct 
> references to the interpreter (I think this needs some 
> re-thinking ...) Anyway: If we once have more than one 
> ControlFlow impl (not necessarily in the cocoon-cvs but maybe 
> outside) this will become a problem!
> >  
> >
> 
> Exactly. Furthermore, and because it's an internal class, the 
> FOM_Cocoon 
> class exposes lots of methods that should not normally be used by 
> application code and potentially open the door to "smart" abuses.
> 
> >>So I added a new method to "cocoon" that sets up an object 
> just as if 
> >>it were an Avalon component by honoring the various lifecycle 
> >>interfaces.
> >>
> >>Some useful lifecycle interfaces to implement are of course 
> LogEnabled 
> >>and Serviceable, but also Contextualizable, which gives 
> access to the 
> >>object model through the ContextHelper class.
> >>
> >>Example:
> >>  var foo = new Foo();
> >>  cocoon.setupObject(foo);
> >>  foo.doIt("blah");
> >>
> >>This way of setting up object respects IOC, avoids using the very
> >>specific "FOM_Cocoon" class and gently educates people to the good 
> >>things provided by Avalon.
> >>
> >>WDYT?
> >>    
> >>
> >
> >I like your solution - big +1 to add it to the FOM!
> >This also means that this object can used as Avalon 
> components outside 
> >of flowscript, doesn't it?
> >  
> >
> 
> Sure! That's why I wrote that it "gently educates people" to Avalon. 
> Once people will have implemented lifecycle interfaces, the 
> next step is 
> to declare the component in cocoon.xconf and move to the regular 
> component lookup mechanism.

indeed, a very good idea!

--
Reinhard


Mime
View raw message