cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: Introducing IOC for Java classes created in flowscript
Date Thu, 20 Nov 2003 16:49:07 GMT
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.

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.

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com



Mime
View raw message