RE: Introducing IOC for Java classes created in flowscript
-Original Message- From: Christopher Oliver [mailto:[EMAIL PROTECTED] Sent: Friday, November 21, 2003 5:47 PM To: [EMAIL PROTECTED] Subject: Re: Introducing IOC for Java classes created in flowscript See Interpreter.java in the example package of ftp://ftp.primaryinterface.com/pub/javacAPI/javacAPI.zip. It provides a CompilingClassLoader that implements findClass() by using the Eclipse java compiler to compile source files. By combining this with Rhino's ability to dynamically use custom classloaders (see http://www.mozilla.org/rhino/rhino15R4.html Scripting classes from any class loader) you should be able to create a Flowscript development environment that doesn't require the explicit use of javac. I am a little behind with mailing list.. ftp://ftp.primaryinterface.com/pub/javacAPI/javacAPI.zip - this address is no longer valid (host not found?). Where can I find this file? -- Leszek Gawron
RE: Introducing IOC for Java classes created in flowscript
You no longer need it, as it is in CVS already - and therefore in 2.1.4 release. To use the compiling classloader, edit the cocoon.xconf, find //flow-interpreters/[EMAIL PROTECTED]'javascript']. Add in a node classpath/classpath that specifies the path to your java source code. Restart your servlet container once, and from then on, you will not need to restart your container, classes will be recompiled on demand. Well cool! I take it that is what you are after. Not really ... I wanted to look at the code to see how this magic is being achieved :). I assume the source is not in the CVS. -- Leszek Gawron
Re: Introducing IOC for Java classes created in flowscript
Leszek Gawron wrote: You no longer need it, as it is in CVS already - and therefore in 2.1.4 release. To use the compiling classloader, edit the cocoon.xconf, find //flow-interpreters/[EMAIL PROTECTED]'javascript']. Add in a node classpath/classpath that specifies the path to your java source code. Restart your servlet container once, and from then on, you will not need to restart your container, classes will be recompiled on demand. Well cool! I take it that is what you are after. Not really ... I wanted to look at the code to see how this magic is being achieved :). I assume the source is not in the CVS. http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/java/org/apache/cocoon/components/flow/javascript/fom/CompilingClassLoader.java Upayavira
RE: Introducing IOC for Java classes created in flowscript
Sylvain Wallez wrote: We'll end up with 3 new methods on cocoon: - setupObject(object), - createObject(classname) (or summon, new, instanciate) - disposeObject(object). What do you think? +1 I'm way behind my mails, is this already implemented? BTW, wasn't there a discussion about renaming getComponent() to lookup()? Carsten
RE: Introducing IOC for Java classes created in flowscript
From: Carsten Ziegeler Sylvain Wallez wrote: We'll end up with 3 new methods on cocoon: - setupObject(object), - createObject(classname) (or summon, new, instanciate) - disposeObject(object). What do you think? +1 I'm way behind my mails, is this already implemented? BTW, wasn't there a discussion about renaming getComponent() to lookup()? Not that I know ... -- Reinhard
Re: Introducing IOC for Java classes created in flowscript
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
We'll end up with 3 new methods on cocoon:
- setupObject(object),
- createObject(classname) (or summon, new, instanciate)
- disposeObject(object).
What do you think?
+1
I'm way behind my mails, is this already implemented?
setupObject is already there.
BTW, wasn't there a discussion about renaming getComponent() to lookup()?
Not that I know, but I like it as it's more consistent with plain old
Java code. Now I think we should keep the -Component suffix since the
cocoon object is more than a ServiceManager.
So what about lookupComponent() ?
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
RE: Introducing IOC for Java classes created in flowscript
Sylvain Wallez wrote: Carsten Ziegeler wrote: BTW, wasn't there a discussion about renaming getComponent() to lookup()? Not that I know, but I like it as it's more consistent with plain old Java code. Now I think we should keep the -Component suffix since the cocoon object is more than a ServiceManager. So what about lookupComponent() ? +1 Component is fine. lookup is better than get. But can we keep support for getComponent in the 2.1 branch? I think a lot of users already rely on it. Unico
Re: Introducing IOC for Java classes created in flowscript
Unico Hommes wrote:
Sylvain Wallez wrote:
snip/
So what about lookupComponent() ?
+1
Component is fine. lookup is better than get. But can we keep support for getComponent in the 2.1 branch? I think a lot of users already rely on it.
Of course, as it is part of the released contract. It will only be
deprecated in favor of the better name.
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
Re: Introducing IOC for Java classes created in flowscript
Stefano Mazzocchi wrote:
On 21 Nov 2003, at 09:45, Sylvain Wallez wrote:
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
..
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.
To make it even more avalonish, this method should instantiate
object as well. So it will become:
var foo = cocoon.summonObject(com.mycompany.Foo);
Good idea. But I'm not sure summon is a so common word (I had to
look in a dictionary). What about the more traditional createObject
or instanciateObject?
How about simply
var foo = cocoon.getComponent(com.mycompany.Foo);
and trying to do role to class lookup transparently?
I'm not comfortable with this transparently which may fool the user in
believing she's using real avalon components when these are just fake
ones whose lifestyle (threadsafe,etc) should be handled by the flowscript.
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
Re: Introducing IOC for Java classes created in flowscript
Michael Hartle wrote:
Sylvain Wallez wrote:
Bertrand Delacretaz wrote:
Le Jeudi, 20 nov 2003, à 18:12 Europe/Zurich, Sylvain Wallez a écrit :
...Rhino also provides some very easy solutions to this:
- http://www.mozilla.org/rhino/tutorial.html#ImplementingInterfaces
- paragraph JavaAdapter constructor at
http://www.mozilla.org/rhino/scriptjava.html
ok, cool, I wasn't aware of this, looks similar to what BeanShell does.
The advantage with BeanShell is that the syntax *is* java - one can
prototype in script and later move the code to compilable classes
(just FYI - I don't mean we should switch now ;-)
Sounds interesting. But you know the initial requirement for any
flowscript language: continuations...
If I understood Bertrands hint towards BeanShell right, it would allow
the people who are affraid of writing real Java code to script an
object which is then used in the flowscript we have today - not
replacing the current continuation language, but easing the transition
for scripters towards Java for objects to be called from the flowscript.
And also the other way around: BeanShell would allow people who are
reluctant to using server-side JS to use the familiar Java syntax. But
once again, the first requirement is to have continuation support.
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
Re: Introducing IOC for Java classes created in flowscript
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
..
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.
To make it even more avalonish, this method should instantiate object
as well. So it will become:
var foo = cocoon.summonObject(com.mycompany.Foo);
Good idea. But I'm not sure summon is a so common word (I had to look
in a dictionary). What about the more traditional createObject or
instanciateObject?
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
Re: Introducing IOC for Java classes created in flowscript
Le Vendredi, 21 nov 2003, à 11:11 Europe/Zurich, Michael Hartle a écrit : Sylvain Wallez wrote: ...And also the other way around: BeanShell would allow people who are reluctant to using server-side JS to use the familiar Java syntax. But once again, the first requirement is to have continuation support. I think there still some misunderstanding; BeanShell does not provide continuations and is not suited for running as a flowscript language like the Rhino JS (with its continuation support) does - here we agree. But thats not the point of Bertrand, as beanShell can turn a script into a Java object which in turn can be used in a typical, today JS flowscript. That's what I meant. ..Instead of an object of a Java class Foo being hardcoded (and supposedly feared by hardcore scripters due to compilation/packaging requirements), it would result into something along the lines of var foo = BeanShell.newObjectFromScript(myScriptedBusinessLogic.bs); cocoon.setupObject(foo); foo.doIt(blah); ... Exactly: allowing BeanShell (or any BSF) scripts could be used not only for Generators and Actions (as the BSF block currently does), but for scriptable business logic (and why not transformers or serializers by the way). In this context, BSF scripts do not need any continuation support, they're used as java objects would be. Depending on how you look at it, it might open wide avenues or a can of worms ;-) But being able to prototype business logic in interpreted java code would be a big plus IMHO. Not to mention a great teaching tool. -Bertrand
Re: Introducing IOC for Java classes created in flowscript
Michael Hartle wrote:
Sylvain Wallez wrote:
snip/
If I understood Bertrands hint towards BeanShell right, it would
allow the people who are affraid of writing real Java code to
script an object which is then used in the flowscript we have today
- not replacing the current continuation language, but easing the
transition for scripters towards Java for objects to be called from
the flowscript.
And also the other way around: BeanShell would allow people who are
reluctant to using server-side JS to use the familiar Java syntax.
But once again, the first requirement is to have continuation support.
I think there still some misunderstanding; BeanShell does not provide
continuations and is not suited for running as a flowscript language
like the Rhino JS (with its continuation support) does - here we
agree. But thats not the point of Bertrand, as beanShell can turn a
script into a Java object which in turn can be used in a typical,
today JS flowscript.
Instead of an object of a Java class Foo being hardcoded (and
supposedly feared by hardcore scripters due to compilation/packaging
requirements), it would result into something along the lines of
var foo = BeanShell.newObjectFromScript(myScriptedBusinessLogic.bs);
cocoon.setupObject(foo);
foo.doIt(blah);
showing the example in conjunction with your proposed extension to
honour lifecycle interfaces. Or putting it the other way around, the
previously shown
var foo = new Foo();
cocoon.setupObject(foo);
foo.doIt(blah);
Foo class written in Java certainly does not have any
continuation-related extension - nor would the BeanShell-resulting
object need it, or ?
Ok, I understand the point. I've been thinking long ago about a
CompilingClassLoader, i.e a classloader to which we don't give .class
files, but .java files and that compiles them on the fly and recompiles
them automatically when needed. BeanShell may provide something similar
without needing to write this complex classloader.
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
Re: Introducing IOC for Java classes created in flowscript
Ok, I understand the point. I've been thinking long ago about a CompilingClassLoader, i.e a classloader to which we don't give .class files, but .java files and that compiles them on the fly and recompiles them automatically when needed. BeanShell may provide something similar without needing to write this complex classloader. Well, we have something for XSP ...don't we? -- Torsten
Re: Introducing IOC for Java classes created in flowscript
Sylvain Wallez wrote: Vadim Gritsenko wrote: Sylvain Wallez wrote: .. 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. To make it even more avalonish, this method should instantiate object as well. So it will become: var foo = cocoon.summonObject(com.mycompany.Foo); Good idea. But I'm not sure summon is a so common word (I had to look in a dictionary). What about the more traditional createObject or instanciateObject? Of course. Summon there was just for fun. createObject() will do just fine; instantiate is a bit worse (there are issues with the spelling ;-) Vadim
Re: Introducing IOC for Java classes created in flowscript
Bertrand Delacretaz dijo: ..Instead of an object of a Java class Foo being hardcoded (and supposedly feared by hardcore scripters due to compilation/packaging requirements), it would result into something along the lines of var foo = BeanShell.newObjectFromScript(myScriptedBusinessLogic.bs); cocoon.setupObject(foo); foo.doIt(blah); ... Exactly: allowing BeanShell (or any BSF) scripts could be used not only for Generators and Actions (as the BSF block currently does), but for scriptable business logic (and why not transformers or serializers by the way). In this context, BSF scripts do not need any continuation support, they're used as java objects would be. Depending on how you look at it, it might open wide avenues or a can of worms ;-) But being able to prototype business logic in interpreted java code would be a big plus IMHO. Not to mention a great teaching tool. +1 Best Regards, Antonio Gallardo
Re: Introducing IOC for Java classes created in flowscript
Le Vendredi, 21 nov 2003, à 12:54 Europe/Zurich, Vadim Gritsenko a écrit : ...Of course. Summon there was just for fun. createObject() will do just fine; instantiate is a bit worse (there are issues with the spelling ;-) Too late. Someone's been lurking here, you'll see summonObject() calls all over the next Microsoft API ;-) -Bertrand
Re: Introducing IOC for Java classes created in flowscript
Sylvain Wallez wrote:
[...]
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.
[...]
Example:
var foo = new Foo();
cocoon.setupObject(foo);
foo.doIt(blah);
This looks quite interesting and definitely useful.
But I've got a question:
When I obtain a component in a flowscript, I have to
release it before sendPage(). So, if my foo object uses
components, does it have to release them before a
sendPage() occurs in a script?
class Foo implements Serviceable {
public void service(ServiceManager manager) {
myComponent = (MyComponent)
manager.lookup(MyComponent.ROLE);
}
...
}
cocoon.summonObject(Packages.bar.Foo.class.getName());
foo.doIt(blah);
foo.releaseComponents();
cocoon.sendPageAndWait(...);
Is this correct?
Thank you in advance,
-- Andreas
Re: Introducing IOC for Java classes created in flowscript
See Interpreter.java in the example package of ftp://ftp.primaryinterface.com/pub/javacAPI/javacAPI.zip. It provides a CompilingClassLoader that implements findClass() by using the Eclipse java compiler to compile source files. By combining this with Rhino's ability to dynamically use custom classloaders (see http://www.mozilla.org/rhino/rhino15R4.html Scripting classes from any class loader) you should be able to create a Flowscript development environment that doesn't require the explicit use of javac. Regards, Chris Torsten Curdt wrote: Ok, I understand the point. I've been thinking long ago about a CompilingClassLoader, i.e a classloader to which we don't give .class files, but .java files and that compiles them on the fly and recompiles them automatically when needed. BeanShell may provide something similar without needing to write this complex classloader. Well, we have something for XSP ...don't we? -- Torsten
Re: Introducing IOC for Java classes created in flowscript
Andreas Hartmann wrote:
Sylvain Wallez wrote:
[...]
Example:
var foo = new Foo();
cocoon.setupObject(foo);
foo.doIt(blah);
This looks quite interesting and definitely useful.
But I've got a question:
When I obtain a component in a flowscript, I have to release it before
sendPage(). So, if my foo object uses components, does it have to
release them before a sendPage() occurs in a script?
Sure, unless, of course, when you know that these components are ThreadSafe.
So the wisest way is IMO to lookup as late as possible and release as
soon as possible. Ideally, both should be in the same method.
But there are cases when this is not possible (because of some state to
keep), and then an explicit release method is needed.
class Foo implements Serviceable {
public void service(ServiceManager manager) {
myComponent = (MyComponent)
manager.lookup(MyComponent.ROLE);
}
...
}
cocoon.summonObject(Packages.bar.Foo.class.getName());
foo.doIt(blah);
foo.releaseComponents();
cocoon.sendPageAndWait(...);
Is this correct?
Yes, but in that case, you'll have to be careful to no more use foo
after sendPageAndWait().
And Avalon provides the Disposable interface just for this. The contract
is that after dispose(), no other method will be called on a component.
So this is where all cleanup is done.
Now what about adding a disposeObject on cocoon that would be the
counterpart of setupObject? It would call it's dispose() method if it
implements the Disposable interface.
We'll end up with 3 new methods on cocoon:
- setupObject(object),
- createObject(classname) (or summon, new, instanciate)
- disposeObject(object).
What do you think?
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
Re: Introducing IOC for Java classes created in flowscript
Christopher Oliver wrote:
See Interpreter.java in the example package of
ftp://ftp.primaryinterface.com/pub/javacAPI/javacAPI.zip. It provides
a CompilingClassLoader that implements findClass() by using the
Eclipse java compiler to compile source files. By combining this with
Rhino's ability to dynamically use custom classloaders (see
http://www.mozilla.org/rhino/rhino15R4.html Scripting classes from
any class loader) you should be able to create a Flowscript
development environment that doesn't require the explicit use of javac.
That's super-cool, and opens a lot of interesing perspectives!
How can we use this code? The license looks ASF-like, but it would be
interesting if it could be hosted here, so that we can extend it and
build on it. I'm mainly thinking of adding automatic reload.
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
RE: Introducing IOC for Java classes created in flowscript
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
Re: Introducing IOC for Java classes created in flowscript
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
Re: Introducing IOC for Java classes created in flowscript
Le Jeudi, 20 nov 2003, à 17:49 Europe/Zurich, Sylvain Wallez a écrit : ...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... Just wildthinking here: I've been using BeanShell (http://www.beanshell.org/) recently, and with it you can very easily write scripts that implement java interfaces. This means that BeanShell (dunno if BSF does this too) scripts could be called from flow *and* interpreted *and* implement Avalon or Cocoon interfaces. I haven't thought about all implications but it might be a nice intermediate solution between limited interpreted stuff and full-blown java coding. ...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... So maybe scripting Avalon interfaces could be a first step in this education? Again, just wild thoughts - fire at will ;-) -Bertrand
Re: Introducing IOC for Java classes created in flowscript
Bertrand Delacretaz wrote:
Le Jeudi, 20 nov 2003, à 17:49 Europe/Zurich, Sylvain Wallez a écrit :
...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...
Just wildthinking here: I've been using BeanShell
(http://www.beanshell.org/) recently, and with it you can very easily
write scripts that implement java interfaces.
This means that BeanShell (dunno if BSF does this too) scripts could
be called from flow *and* interpreted *and* implement Avalon or Cocoon
interfaces. I haven't thought about all implications but it might be a
nice intermediate solution between limited interpreted stuff and
full-blown java coding.
Rhino also provides some very easy solutions to this:
- http://www.mozilla.org/rhino/tutorial.html#ImplementingInterfaces
- paragraph JavaAdapter constructor at
http://www.mozilla.org/rhino/scriptjava.html
...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...
So maybe scripting Avalon interfaces could be a first step in this
education?
Mmmh... Not sure it would be a good education ;-)
But it can certainly be useful for quick hack prototypes!
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
Re: Introducing IOC for Java classes created in flowscript
Ugo Cei wrote:
Sylvain Wallez wrote:
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.
At first sight, this looks incredibly useful. Bug +1 from me!
Thanks. The main purpose is to avoid the dependency on FOM_Cocoon. Doing
it the Avalon way is an additional bonus ;-)
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
RE: Introducing IOC for Java classes created in flowscript
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
Re: Introducing IOC for Java classes created in flowscript
Le Jeudi, 20 nov 2003, à 18:12 Europe/Zurich, Sylvain Wallez a écrit : ...Rhino also provides some very easy solutions to this: - http://www.mozilla.org/rhino/tutorial.html#ImplementingInterfaces - paragraph JavaAdapter constructor at http://www.mozilla.org/rhino/scriptjava.html ok, cool, I wasn't aware of this, looks similar to what BeanShell does. The advantage with BeanShell is that the syntax *is* java - one can prototype in script and later move the code to compilable classes (just FYI - I don't mean we should switch now ;-) So maybe scripting Avalon interfaces could be a first step in this education? Mmmh... Not sure it would be a good education ;-) But it can certainly be useful for quick hack prototypes! Even more if the syntax was java! Food for thought I guess.. -Bertrand
Re: Introducing IOC for Java classes created in flowscript
Bertrand Delacretaz wrote:
Le Jeudi, 20 nov 2003, à 18:12 Europe/Zurich, Sylvain Wallez a écrit :
...Rhino also provides some very easy solutions to this:
- http://www.mozilla.org/rhino/tutorial.html#ImplementingInterfaces
- paragraph JavaAdapter constructor at
http://www.mozilla.org/rhino/scriptjava.html
ok, cool, I wasn't aware of this, looks similar to what BeanShell does.
The advantage with BeanShell is that the syntax *is* java - one can
prototype in script and later move the code to compilable classes
(just FYI - I don't mean we should switch now ;-)
Sounds interesting. But you know the initial requirement for any
flowscript language: continuations...
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
Re: Introducing IOC for Java classes created in flowscript
Sylvain Wallez wrote: Bertrand Delacretaz wrote: Le Jeudi, 20 nov 2003, à 18:12 Europe/Zurich, Sylvain Wallez a écrit : ...Rhino also provides some very easy solutions to this: - http://www.mozilla.org/rhino/tutorial.html#ImplementingInterfaces - paragraph JavaAdapter constructor at http://www.mozilla.org/rhino/scriptjava.html ok, cool, I wasn't aware of this, looks similar to what BeanShell does. The advantage with BeanShell is that the syntax *is* java - one can prototype in script and later move the code to compilable classes (just FYI - I don't mean we should switch now ;-) Sounds interesting. But you know the initial requirement for any flowscript language: continuations... If I understood Bertrands hint towards BeanShell right, it would allow the people who are affraid of writing real Java code to script an object which is then used in the flowscript we have today - not replacing the current continuation language, but easing the transition for scripters towards Java for objects to be called from the flowscript. Best regards, Michael Hartle, Hartle Klug Consulting GmbH
Re: Introducing IOC for Java classes created in flowscript
Sylvain Wallez wrote: . 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. To make it even more avalonish, this method should instantiate object as well. So it will become: var foo = cocoon.summonObject(com.mycompany.Foo); Vadim
Re: Introducing IOC for Java classes created in flowscript
Le Vendredi, 21 nov 2003, à 02:49 Europe/Zurich, Michael Hartle a écrit : Sylvain Wallez wrote: Bertrand Delacretaz wrote: ...The advantage with BeanShell is that the syntax *is* java - one can prototype in script and later move the code to compilable classes (just FYI - I don't mean we should switch now ;-) Sounds interesting. But you know the initial requirement for any flowscript language: continuations... If I understood Bertrands hint towards BeanShell right, it would allow the people who are affraid of writing real Java code to script an object which is then used in the flowscript we have today - not replacing the current continuation language, but easing the transition for scripters towards Java for objects to be called from the flowscript. Exactly - and it would be a nice prototyping environment as well, with the ability to easily move scripted BeanShell code to java classes later on. -Bertrand
