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 that specifies the path to your java
source code. Restart your
> 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 that specifies the path to your java
> source code. Restart your servlet cont
Leszek Gawron wrote:
-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
> -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 exa
Unico Hommes wrote:
Sylvain Wallez wrote:
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
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 sinc
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
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 i
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 abo
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 in
On 21 Nov 2003, at 12:22, 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. BeanShel
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
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
Go ahead. I wrote the code so if you need any change to the license,
just let me know.
Sylvain Wallez wrote:
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 fi
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 t
Sylvain Wallez wrote:
[...]
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.
Yes, this idea came into my mind too (it would
be strange if not the full lifecycle hand
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, i
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 cl
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
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 "instanciate
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 definitel
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
a
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("myScriptedBus
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
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
Michael Hartle wrote:
Sylvain Wallez wrote:
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, b
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
Sylvain Wallez wrote:
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
- par
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
..
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
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 C
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 con
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
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 giv
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://ww
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/scr
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
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
> convenien
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 depende
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
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 awa
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 ju
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!
Ugo
--
Ugo Cei - Consorzio di Bioingegneria e Informatica Medica
P.
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
42 matches
Mail list logo
