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
