Using BSF to drive OpenOffice.org with the BSF scripting engines ... [Fwd: Re: [udk-dev] A request for "com.sun.star.lang.XEventListener"]

["Rony G. Flatscher" <Ro...@wu-wien.ac.at>]

Hi there,

just thought that maybe those who are interested/working with BSF as 
developer/user in general are interested in this too. It is from a 
posting to a developer list of "www.OpenOffice.org" (opensource version 
of Sun's "StarOffice").

It *is* possible to script OpenOffice.org (OOo) via BSF using the 
BSF-supported languages. Also, since last October OOo version 2.0 
contains a Java implemented scripting framework for OOo, which allows 
creating and storing macros with OOo.

As some of you may know I have been working on the Rexx and Object 
Rexx/ooRexx BSF scripting engine and have with the help of students 
researched the possiblities of scripting OOo via its Java-interface from 
BSF. At the moment a beta version named "BSF4Rexx" is available for 
those who want to take a look at it. That package contains an unofficial 
version of BSF (with some fixes for the dynamic creation of event 
listeners and a special section needed to support the dynamic creation 
of OOo event listeners).

Some more infos (including URLs) are given in the forwarded message below.

Regards,

---rony

P.S.: The fixes for the dynamic creation of event listeners will be 
incorporated one way or the other into BSF, at the moment Sanjiva is 
kind enough to look over the code.




-------- Original Message --------
Subject: 	Re: [udk-dev] A request for "com.sun.star.lang.XEventListener"
Date: 	Fri, 17 Feb 2006 17:25:16 +0100
From: 	Rony G. Flatscher <Ro...@wu-wien.ac.at>
Reply-To: 	dev@udk.openoffice.org
To: 	dev@udk.openoffice.org
References: 	<op...@wu-wien.ac.at> 
<dt...@staroffice-news.germany.sun.com>



Hi Kay,
>> according to the documentation "com.sun.star.lang.XEventListener" 
>> does not report to implement the Java interface 
>> "java.util.EventListener". It seems that "java.beans.Introspector" is 
>> not able to identify/locate the OOo EventListeners breaking generic 
>> reflective code as a result.
> what would be the advantage of the Introspector being able to identify 
> event listeners? 
Every Java program relying on the abliity of the Introspector to 
identify event listeners will be able to rely on the OOo Java interfaces 
as well. Or put differently: every Java code  breaks with OOo Java event 
listeners, because OOo does not classify its event listeners of type <>.
> What would the usage scenario look like? Do you have an example at hand?
Yes, I think so. An (rather important) example might be:

    <http://jakarta.apache.org/bsf>

The "Bean Scripting Framework" (BSF) is a Java opensource framework 
allowing Java programs to easily invoke scripts in non-Java languages 
and also supplies functionality to non-Java scripting engines to 
interface with Java. This way non-Java programs are able to interface 
and take advantage of Java.

I have been using BSF to allow the free, opensource, multiplatform 
scripting language ooRexx (cf. <http://www.ooRexx.org>) to drive OOo via 
Java. (The generic support for this ooRexx-to-Java bridge is dubbed 
"BSF4Rexx" and will get contain the generic support for OOo, making it 
considerably easy for script coders to drive OOo in a platform 
independent manner.)
[You can take a look at the following work: 
<http://wi.wu-wien.ac.at/rgf/diplomarbeiten/BakkStuff/2005/200511_OOo-Ahammer/200511_OOoAutomation.pdf> 
which contains nutshell examples of driving OOo from ooRexx, showing the 
code and images of the resulting OOo window. All examples run under 
Linux *and* Windows, with the exception of the MS Access sample, of 
course. This work was updated in 2006-11. There is another student who 
is about to finalize another work, creating nutshell examples of using 
ooRexx as a macro language for OOo 2.x.]

With the advent of OOo 2.0 a Java based scripting framework is 
available, which I use to plug in ooRexx into OOo, allowing it to be 
used as a scripting language beside OOo Basic, Python, JavaScript 
(Rhino), BeanShell. (It would be now a matter of a few minutes to add 
all the BSF supported scripting languages using the ooRexx 
implementation as a template. Will announce that fact, once the ooRexx 
implementation goes "Golden") Just to give you an idea about the 
"complexity" of this part of the task (besides getting acquainted with 
the OOo scripting framework itself), here is the necessary code to make 
ooRexx available as a macro language to OOo:

--------------- cut here --------------

ScriptSourceModel.invoke(...):

    // ... cut ...

    BSFManager mgr = new BSFManager();              
    Vector     args= new Vector(aParams.length+1);  

    try // create arguments for ooRexx
    {
        int i;

           // rgf, make XScriptContext available to script
           // 2006-01-06, set entries into BSF registry for retrieval by invoked Rexx script (available in every Rexx scope)
        mgr.registerBean(ScriptProviderForooRexx.OOREXX_XSCRIPTCONTEXT_KEY,  ScriptContext.createContext(m_xModel, m_xContext, m_xMultiComponentFactory));
        mgr.registerBean(ScriptProviderForooRexx.OOREXX_VERSION_KEY,        "1.0");

           // add arguments to Vector
        for (i=0;i<aParams.length;i++)
        {
            args.addElement(aParams[i]);    // add argument
        }
    }

    // ... cut (plain vanilla stuff from ScriptSourceModel.invoke(...) ...

    result=mgr.apply(ScriptProviderForooRexx.OOREXX_BSFLANGUAGE, "OOo.ScriptProviderForooRexx", 0, 0, source, null, args);

    if (result == null)
    {
        return new Any(new Type(), null);
    }

    return result;

    // ... cut ...
      

--------------- cut here --------------


Changing a few constants and you could use the same code for dispatching 
JavaScript (Rhino), Jython, JLog (PROLOG) etc. via BSF and the OOo 
scripting framework. (Just to hint at the importance of Java frameworks 
like BSF.)

---

Now, because OOo event handlers do not declare to have the Java 
"java.util.EventListener" implemented (it is actually just a 
classification information, as it is an interface class not defining any 
fields or methods), the generic event handler support of BSF breaks. 
(Due to the opensourceness of BSF I was able to go through the 
respective code and was able to add the support for OOo event handlers; 
but this is a "private" fix, which I doubt that the BSF committers will 
accept for the official distribution. If interested, you could look at 
it at the URL given in the "P.S." below.)

---

As you may know, with Java 1.6 a scripting interface will become 
available with Java (I was serving on the respective JSR-223 group for 
the past years), which will be confined to 1.6. There are plans to 
create a version of BSF which will be compatible with JSR-223, allowing 
earlier versions of Java the same scripting interfaces.

No matter which (scripting interface) version one is interested in, 
supporting event handlers is critical for scripts. So today's 
introspection/reflection Java classes should work with OOo event 
handlers generically as well, ie. without the need for any changes.

Rergards,

---rony

P.S.: The present Beta-version of "BSF4Rexx" including the OOo/UNO 
support can be found together with examples and the source code (OOo 
scripting framework, tweaked BSF for OOo event listeners, etc.) at: 
<http://wi.wu-wien.ac.at/rgf/rexx/bsf4rexx/current/>. Feel free to ask 
questions, should you have any questions.

P.P.S.: Although ooRexx is available for Solaris, I have not yet had the 
time to dig into Solaris in order to port BSF4Rexx to Solaris (one JNI 
file needs to be compiled for it); so if anyone is interested/curious 
and does a port to Solaris of BSF4Rexx, please let me know.