You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Sylvain Wallez <sy...@apache.org> on 2003/11/20 16:29:58 UTC
Introducing IOC for Java classes created in flowscript
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.
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.
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?
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
Posted by Ugo Cei <u....@cbim.it>.
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 "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 ;-)
newObject?
newInstance?
Ugo
--
Ugo Cei - Consorzio di Bioingegneria e Informatica Medica
P.le Volontari del Sangue, 2 - 27100 Pavia - Italy
Phone: +39.0382.525100 - E-mail: u.cei@cbim.it
Re: Introducing IOC for Java classes created in flowscript
Posted by Bertrand Delacretaz <bd...@apache.org>.
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
Posted by Vadim Gritsenko <va...@verizon.net>.
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
Posted by Christian Haul <ha...@informatik.tu-darmstadt.de>.
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
> look in a dictionary). What about the more traditional "createObject"
> or "instanciateObject"?
I like "summon". It has this magic touch and resonates well with the
Avalon saga :-)
Chris.
Re: Introducing IOC for Java classes created in flowscript
Posted by Sylvain Wallez <sy...@apache.org>.
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
Posted by Stefano Mazzocchi <st...@apache.org>.
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?
--
Stefano.
Re: Introducing IOC for Java classes created in flowscript
Posted by Sylvain Wallez <sy...@apache.org>.
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
Posted by Vadim Gritsenko <va...@verizon.net>.
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
Posted by Sylvain Wallez <sy...@apache.org>.
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
Posted by Ugo Cei <u....@cbim.it>.
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.le Volontari del Sangue, 2 - 27100 Pavia - Italy
Phone: +39.0382.525100 - E-mail: u.cei@cbim.it
Re: Introducing IOC for Java classes created in flowscript
Posted by Sylvain Wallez <sy...@apache.org>.
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
Posted by Andreas Hartmann <an...@apache.org>.
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 handling
was supported).
> We'll end up with 3 new methods on "cocoon":
> - setupObject(object),
> - createObject(classname) (or summon, new, instanciate)
> - disposeObject(object).
>
> What do you think?
That would definitely simplify Flowscript development.
-- Andreas
RE: Introducing IOC for Java classes created in flowscript
Posted by Reinhard Poetz <re...@apache.org>.
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
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
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
Posted by Sylvain Wallez <sy...@apache.org>.
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
Posted by Andreas Hartmann <an...@apache.org>.
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
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
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
Posted by Stefano Mazzocchi <st...@apache.org>.
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. BeanShell may provide
>> something similar without needing to write this complex classloader.
>
> Well, we have something for XSP ...don't we?
Yes, the eclipse compiler works like this: you pass a Classloader (for
the class dependencies) and a Inputstream (for the source code) and you
get a Class back. Everything happens in memory.
Keep in mind, though, that if you want to do autoreload, dependency
checking can get *really* nasty, not on compiling but on classloading.
BTW, these issues should be solved by the block manager which isolates
classloading contexts per block.
--
Stefano.
Re: Introducing IOC for Java classes created in flowscript
Posted by Christopher Oliver <re...@verizon.net>.
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 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
>
Re: Introducing IOC for Java classes created in flowscript
Posted by Sylvain Wallez <sy...@apache.org>.
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
Posted by Upayavira <uv...@upaya.co.uk>.
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/component-instance[@name='javascript']. Add in a
>>node <classpath>xxxx</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
Posted by Leszek Gawron <ou...@wlkp.org>.
> 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/component-instance[@name='javascript']. Add in a
> node <classpath>xxxx</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
Posted by Upayavira <uv...@upaya.co.uk>.
Leszek Gawron wrote:
>>-----Original Message-----
>>From: Christopher Oliver [mailto:res1cf5x@verizon.net]
>>Sent: Friday, November 21, 2003 5:47 PM
>>To: dev@cocoon.apache.org
>>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?
>
>
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/component-instance[@name='javascript']. Add in a
node <classpath>xxxx</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.
Regards, Upayavira
RE: Introducing IOC for Java classes created in flowscript
Posted by Leszek Gawron <ou...@wlkp.org>.
> -----Original Message-----
> From: Christopher Oliver [mailto:res1cf5x@verizon.net]
> Sent: Friday, November 21, 2003 5:47 PM
> To: dev@cocoon.apache.org
> 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
Posted by Christopher Oliver <re...@verizon.net>.
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
Posted by Torsten Curdt <tc...@vafer.org>.
> 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
Posted by Sylvain Wallez <sy...@apache.org>.
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
Posted by Bertrand Delacretaz <bd...@apache.org>.
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
Posted by Michael Hartle <mh...@hartle-klug.com>.
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
>>>>> - 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.
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 ?
Best regards,
Michael Hartle,
Hartle & Klug Consulting GmbH
Re: Introducing IOC for Java classes created in flowscript
Posted by Sylvain Wallez <sy...@apache.org>.
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
Posted by Bertrand Delacretaz <bd...@apache.org>.
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
Re: Introducing IOC for Java classes created in flowscript
Posted by Michael Hartle <mh...@hartle-klug.com>.
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
Posted by Sylvain Wallez <sy...@apache.org>.
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
Posted by Bertrand Delacretaz <bd...@apache.org>.
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
Posted by Sylvain Wallez <sy...@apache.org>.
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: A general Note
Posted by Sylvain Wallez <sy...@apache.org>.
JD Daniels wrote:
>I just wanted to take moment and thank the cocoon community.
>
>Cocoon kicks butt.
>
>I make small to medium small business / personal web applications.
>Nothing fancy, basically alot of xsp + xsl templates (These alone match PHP I think)
>After the initial learning curve (which seems to extend a bit whenever I need something new), cocoon delivers speed and maintainability.
>
>I enjoy watching the dev list to see what is coming next. I have a lot of trouble with java in general (learning as I go with no formal training).
>However I hate PHP and perl now. I actually regret the time I spent developing with them.
>
>The time saved from endless hours of scanning thousands of lines of php code to change ridiculous things like html table layouts, or an email notification has allowed me to keep my small-town, small business viable. I am able to work at home with my wife and children around me.
>
>There are alot of ambitious goals for cocoon, and sometimes the lists gets so excited about new stuff, they might miss what has already been accomplished. But for me, Cocoon's existence has made a HUGE difference in my work *and* my home life.
>
>Thanks Guys :)
>
>
Thank you for letting us know.
Cocoon has this "something special" compared to other frameworks: it is
a software that you have a personal relation with, a feeling I already
encountered in a nearby domain with Macintosh computers. I don't exactly
know where this feeling comes from with Cocoon: is it because there are
always some different creative ways to achieve your goal, with this
large box full of multi-colored Lego bricks? Is it because you "feel"
your site when designing sitemap patterns? Is it because it allows fast
yet powerful work? Is it because you just
save-and-reload-and-wow!-it's-nice?
Comparing with Macs, I think the common point is that both allow you to
manipulate very high level abstractions without seeing them, or at least
not too much. This is clearly outlined when you express the pleasure you
have to use these hundreds of thousands line of Java without mastering Java.
One sure thing is that the Cocoon community is a nice and friendly place
to be. And this certainly explains why this community's baby is so
enjoyable. Have you looked at Stefano's slides at the GetTogether? If
not, go there, look at the pictures and you'll understand this.
BTW, can we see your sites on the internet ?
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: Scriptable objects with BeanShell
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le Lundi, 24 nov 2003, à 22:02 Europe/Zurich, Upayavira a écrit :
> ...Then I've effectively created a class. But it seems a bit around
> the houses to me...
ok, see your point now, thanks.
Don't close the door on scripting stuff too soon though, there's a lot
happening with Groovy [1] (not to mention LOAF;-) these days, even
though it is very new it looks very interesting for writing test cases.
-Bertrand
[1] http://groovy.codehaus.org
Re: Scriptable objects with BeanShell
Posted by Upayavira <uv...@upaya.co.uk>.
Bertrand Delacretaz wrote:
> Le Lundi, 24 nov 2003, à 21:05 Europe/Zurich, Upayavira a écrit :
>
>> ...From looking at the BeanShell docs, the Java is definitely
>> 'scripted' java, and lacks Java's object orientedness...
>
>
> But what about this example from the BeanShell docs:
>
> buttonHandler = new ActionListener() {
> actionPerformed( event ) {
> print(event);
> }
> };
>
> button = new JButton();
> button.addActionListener( buttonHandler );
> frame(button);
>
> A new behaviour for ActionListener is indeed created in a script.
> Isn't this a good example of object orientedness, do you have a
> counterexample?
Yup. But I can't code a class called User, and then invoke it with 'new
User()', I have to do it inline.
I guess I could do:
newUser() {
user = new Object() {
setUsername(username) {
this.username = username;
}
validatePassword(password) {
...etc
}
}
And then do:
myUser = newUser();
myUser.setUsername("upayavira");
if (myUser.validatePassword("xyz")) {
cocoon.sendPage(".....");
} else {
...
}
Then I've effectively created a class. But it seems a bit around the
houses to me.
Regards, Upayavira
Re: Scriptable objects with BeanShell
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le Lundi, 24 nov 2003, à 21:05 Europe/Zurich, Upayavira a écrit :
> ...From looking at the BeanShell docs, the Java is definitely
> 'scripted' java, and lacks Java's object orientedness...
But what about this example from the BeanShell docs:
buttonHandler = new ActionListener() {
actionPerformed( event ) {
print(event);
}
};
button = new JButton();
button.addActionListener( buttonHandler );
frame(button);
A new behaviour for ActionListener is indeed created in a script.
Isn't this a good example of object orientedness, do you have a
counterexample?
-Bertrand
Re: A general Note
Posted by Tony Collen <co...@umn.edu>.
JD Daniels wrote:
> I just wanted to take moment and thank the cocoon community.
>
> Cocoon kicks butt.
>
> I make small to medium small business / personal web applications.
> Nothing fancy, basically alot of xsp + xsl templates (These alone match PHP
> I think)
> After the initial learning curve (which seems to extend a bit whenever I
> need something new), cocoon delivers speed and maintainability.
>
> I enjoy watching the dev list to see what is coming next. I have a lot of
> trouble with java in general (learning as I go with no formal training).
> However I hate PHP and perl now. I actually regret the time I spent
> developing with them.
I came from the PHP world as well. I was able to get a lot of work done, and it introduced me to
server-side programming. I had quickly gotten fed up with mixing html with my code, and learned how
to use some of the templating libraries. The problem with them was that they were so @#% complex
that I had to look up the syntax every time I wanted to use it. Compared to that, Cocoon is a breeze :D
> The time saved from endless hours of scanning thousands of lines of php code
> to change ridiculous things like html table layouts, or an email
> notification has allowed me to keep my small-town, small business viable. I
> am able to work at home with my wife and children around me.
>
> There are alot of ambitious goals for cocoon, and sometimes the lists gets
> so excited about new stuff, they might miss what has already been
> accomplished. But for me, Cocoon's existence has made a HUGE difference in
> my work *and* my home life.
It is hard to keep up with all of the stuff going on. I haven't had all that much time to dive into
Woody as much as I'd like. Flow was around for a long time before people started using it -- and
now other projects are finally picking up on the idea of using continuations on the web. I'm
excited to see where Cocoon goes after 2.2.
It's awesome to see how something like Cocoon can concretely impact not only people's work, but also
their personal life :)
>
> Thanks Guys :)
>
> JD
>
Regards,
Tony
Re: A general Note
Posted by Stefano Mazzocchi <st...@apache.org>.
On 24 Nov 2003, at 22:38, JD Daniels wrote:
> I just wanted to take moment and thank the cocoon community.
>
> Cocoon kicks butt.
>
> I make small to medium small business / personal web applications.
> Nothing fancy, basically alot of xsp + xsl templates (These alone
> match PHP
> I think)
> After the initial learning curve (which seems to extend a bit whenever
> I
> need something new), cocoon delivers speed and maintainability.
>
> I enjoy watching the dev list to see what is coming next. I have a lot
> of
> trouble with java in general (learning as I go with no formal
> training).
> However I hate PHP and perl now. I actually regret the time I spent
> developing with them.
>
> The time saved from endless hours of scanning thousands of lines of
> php code
> to change ridiculous things like html table layouts, or an email
> notification has allowed me to keep my small-town, small business
> viable. I
> am able to work at home with my wife and children around me.
>
> There are alot of ambitious goals for cocoon, and sometimes the lists
> gets
> so excited about new stuff, they might miss what has already been
> accomplished. But for me, Cocoon's existence has made a HUGE
> difference in
> my work *and* my home life.
>
> Thanks Guys :)
Thank you!
--
Stefano, tasting the warm feeling of these words in this cold, wet and
dark afternoon.
I really needed this. I really did. Thank you.
A general Note
Posted by JD Daniels <jd...@datatrio.com>.
I just wanted to take moment and thank the cocoon community.
Cocoon kicks butt.
I make small to medium small business / personal web applications.
Nothing fancy, basically alot of xsp + xsl templates (These alone match PHP
I think)
After the initial learning curve (which seems to extend a bit whenever I
need something new), cocoon delivers speed and maintainability.
I enjoy watching the dev list to see what is coming next. I have a lot of
trouble with java in general (learning as I go with no formal training).
However I hate PHP and perl now. I actually regret the time I spent
developing with them.
The time saved from endless hours of scanning thousands of lines of php code
to change ridiculous things like html table layouts, or an email
notification has allowed me to keep my small-town, small business viable. I
am able to work at home with my wife and children around me.
There are alot of ambitious goals for cocoon, and sometimes the lists gets
so excited about new stuff, they might miss what has already been
accomplished. But for me, Cocoon's existence has made a HUGE difference in
my work *and* my home life.
Thanks Guys :)
JD
Re: Scriptable objects with BeanShell
Posted by Upayavira <uv...@upaya.co.uk>.
Bertrand Delacretaz wrote:
>
> 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 but
>>> it might be a nice intermediate solution between limited
>>> interpreted stuff and full-blown java coding.
>>
>>
>> Can you say more about how you do this? Give some examples? I would
>> find that very useful.
>
>
> Still in wildthoughts mode here, I haven't tested this:
>
> 1) A BeanShellWrapper Component initializes BeanShell and provides
> some useful beans that scripts can access (similar to what the
> current ScriptGenerator does).
>
> Maybe BSF instead of BeanShell (as BSF can use BeanShell as a script
> engine anyway), but I don't know if BSF does all this.
>
> 2) BeanShellWrapper provides methods for flowscripts to retrieve
> scriptable objects, something like:
>
> IMyBizObject =
> (IMyBizObject)BSFWrapper.createObject(IMyBizObject.class,"MyBusinessScri
> pt.bsl");
>
> At this point the BeanShell "dynamic adapter" feature [1] [2] is used
> to provide an object of the specified interface, something like:
>
> // in BeanShellWrapper:
> public Object createObject(Class clazz,String scriptFilename) {
> // first load scriptFilename in the (or a new) BeanShell
> Interpreter
> ...
> // then cast the interpreter as required, it will call the
> appropriate methods in
> // the script if they exist and complain if not
> return interpreter.getInterface(clazz);
> }
>
> See what I mean? This is only a rough sketch, there are certainly a
> lot of "details" to consider. But it looks like all the essential
> elements are here.
>
> I'm also not sure if one of the BeanShell licenses [3] are ok for
> distributing with Cocoon, but mocks could be used if it is not the case.
>
> Hope this helps,
> -Bertrand
>
>
> [1] http://www.beanshell.org/javadoc/bsh/
> Interpreter.html#getInterface(java.lang.Class)
>
> [2] http://www.beanshell.org/manual/
> bshmanual.html#%22Dummy%22_Adapters_and_Incomplete_Interfaces
>
> [3] http://www.beanshell.org/license.html
>
From looking at the BeanShell docs, the Java is definitely 'scripted'
java, and lacks Java's object orientedness. Therefore, whilst you're
coding in more or less Java, I can't see a great advantage of using
BeanShell over using Rhino. They're both scripted, and thus not able to
create clear interfaces. (In BeanShell you can implement interfaces, but
to do so you have to use 'anonymous classes', which IMO doesn't produce
attractive or easy to read code.
Therefore, I think, for my case, I'm just going to have to use Java for
my objects, to use Unit Tests to test them (rather than bothering to
test them in a servlet environment), and hope for the day when someone
gets Christopher's CompilingClassLoader working so that I can easily
debug Java code from within a servlet.
Regards, Upayavira
Scriptable objects with BeanShell (was: Introducing IOC for Java classes created in flowscript)
Posted by Bertrand Delacretaz <bd...@apache.org>.
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 but it
>> might be a nice intermediate solution between limited interpreted
>> stuff and full-blown java coding.
>
> Can you say more about how you do this? Give some examples? I would
> find that very useful.
Still in wildthoughts mode here, I haven't tested this:
1) A BeanShellWrapper Component initializes BeanShell and provides some
useful beans that scripts can access (similar to what the current
ScriptGenerator does).
Maybe BSF instead of BeanShell (as BSF can use BeanShell as a script
engine anyway), but I don't know if BSF does all this.
2) BeanShellWrapper provides methods for flowscripts to retrieve
scriptable objects, something like:
IMyBizObject =
(IMyBizObject)BSFWrapper.createObject(IMyBizObject.class,"MyBusinessScri
pt.bsl");
At this point the BeanShell "dynamic adapter" feature [1] [2] is used
to provide an object of the specified interface, something like:
// in BeanShellWrapper:
public Object createObject(Class clazz,String scriptFilename) {
// first load scriptFilename in the (or a new) BeanShell
Interpreter
...
// then cast the interpreter as required, it will call the
appropriate methods in
// the script if they exist and complain if not
return interpreter.getInterface(clazz);
}
See what I mean? This is only a rough sketch, there are certainly a lot
of "details" to consider. But it looks like all the essential elements
are here.
I'm also not sure if one of the BeanShell licenses [3] are ok for
distributing with Cocoon, but mocks could be used if it is not the case.
Hope this helps,
-Bertrand
[1]
http://www.beanshell.org/javadoc/bsh/
Interpreter.html#getInterface(java.lang.Class)
[2]
http://www.beanshell.org/manual/
bshmanual.html#%22Dummy%22_Adapters_and_Incomplete_Interfaces
[3] http://www.beanshell.org/license.html
Re: Introducing IOC for Java classes created in flowscript
Posted by Upayavira <uv...@upaya.co.uk>.
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.
Can you say more about how you do this? Give some examples? I would find
that very useful.
Regards, Upayavira
Re: Introducing IOC for Java classes created in flowscript
Posted by Bertrand Delacretaz <bd...@apache.org>.
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
Posted by Reinhard Poetz <re...@apache.org>.
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
Posted by Sylvain Wallez <sy...@apache.org>.
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
Posted by Reinhard Poetz <re...@apache.org>.
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