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 ...
>
> 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!
>
> 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?
--
Reinhard
