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
