-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
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
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
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
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,
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
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
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.
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
Le Vendredi, 21 nov 2003, à 22:20 Europe/Zurich, Upayavira a écrit :
Bertrand Delacretaz wrote:
...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
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
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
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
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
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
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
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 =
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
34 matches
Mail list logo
