You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by "Rony G. Flatscher (Apache)" <ro...@apache.org> on 2018/06/14 18:54:46 UTC

Just a little side note on the scripting framework ...

A friend has LibreOffice installed (due to a better mail-merge-support I understand) and I came up
with a script to help her taking advantage of the writer component. The script is written in ooRexx
for which I authored an OOo scripting provider that works on OOo, making ooRexx an additional macro
language for OOo.

Now, installing that package on her machine the scripts work from outside of LO flawlessly, however
ooRexx does not get registered as another macro language in LO (missing from the "Macro" menu).
After researching this issue for quite some time now, it turns out that LO removed a method in
ClassLoaderFactory and changed the signature of the remaining method by removing the throws clause,
causing a need to compile the script language provider against OOo's ScriptFramework.jar, if the
script provider is to run against OOo, and having the need to compile it separately against LO's
version of ScriptFramework.jar, which is a PITA.

In the case that there are other script provider programmers hanging around, this is what I did in
order to get a single version that runs also against LO, if there is a need to use
ClassLoaderFactory (maybe in the XScript implementation part):

         ... cut ...
            
          // instead of: cl = ClassLoaderFactory.getURLClassLoader( metaData );
          // load and run the method dynamically at runtime:
          Class clfClz=Class.forName("com.sun.star.script.framework.provider.ClassLoaderFactory");
          Class smdClz=Class.forName("com.sun.star.script.framework.container.ScriptMetaData");
          Method meth =clfClz.getMethod("getURLClassLoader", new Class<?>[]{smdClz}  );
          cl=(ClassLoader) meth.invoke(null,  new Object  []{metaData});

         ... cut ...   

Again, this is just a side note for other script provider implementors who get hit by this LO
pecularity.

Also: in the "description.xml" deployment file make sure that  the element
"OpenOffice.org-minimal-version has a value "3.4" or higher (cf.
<https://wiki.documentfoundation.org/Development/Extension_Development>), such that the extension is
not regarded as "legacy" by LO.

In the end, with the above changes, the ooRexx scripting provider again gets accepted as a macro
language for LO.

The reference remains OOo, which has been working in all other aspects of the Macro menu (run, edit,
making the installed macros available etc.) as per the specifications, whereas LO has some problems
in that area (shared scripts not showing up, listing of the script language in the menu disappears,
if the menu got used, still user macros remain visible and executable).

---rony



Re: Just a little side note on the scripting framework ...

Posted by Matthias Seidel <ma...@hamburg.de>.
Hi Rony,

Am 15.06.2018 um 10:49 schrieb Rony G. Flatscher (Apache):
> Hi Mattias,
>
> On 14.06.2018 22:54, Matthias Seidel wrote:
>> Am 14.06.2018 um 20:54 schrieb Rony G. Flatscher (Apache):
>>> A friend has LibreOffice installed (due to a better mail-merge-support I understand) and I came up
>>> with a script to help her taking advantage of the writer component. The script is written in ooRexx
>>> for which I authored an OOo scripting provider that works on OOo, making ooRexx an additional macro
>>> language for OOo.
>> That's very interesting!
>> I know Object Rexx from my times with OS/2 (in fact I am still running
>> it in a VM).
> That's funny, me too!
> ;-)

In fact, even OpenOffice is available for it:
https://www.bitwiseworks.com/products/ports.php#AOO

>
> (At one point in time one could create a password protected OS/2 WPS-Folder in ten lines of Object
> Rexx code using the SOM - system object model - support! Powerful stuff.)
>
> The source code of IBM Object Rexx got handed over to the non-profit SIG Rexx Language Association
> (http://www.rexxla.org), which has been releasing opensource versions under the name of "Open Object
> Rexx (ooRexx)" ever since.
>
> I use ooRexx to teach Business Administration students oo-programming from zero knowledge to
> programming Windows, MS Office, Linux, MacOSX, OpenOffice, platform independent GUIs (awt, swing,
> JavaFX) in *one* semester!
>
> Currently the official 5.0 beta (release quality) version of ooRexx is available for Windows and
> Linux from <https://sourceforge.net/projects/oorexx/files/oorexx/5.0.0beta/>.
>
> There is a MacOSX version that includes the latest ooRexx 5.0 beta together with the Java bridge
> "BSF4ooRexx" at
> <https://sourceforge.net/projects/bsf4oorexx/files/beta/20180312/b4r_600_500_64Bit_macosx-20180324.zip/download>.
>
>
>> Is your scripting provider available somewhere?
> Yes, it is contained in the package BSF4ooRexx, which is a bridge from ooRexx to Java and includes
> among other things special support for OpenOffice programming and can be obtained from
> <https://sourceforge.net/projects/bsf4oorexx/files/beta/20180312/>. Unzip the archive, go into the
> directory "bsf4oorexx/install" and then into "windows" or "linux" and run the "install" script. If
> the installer sees OOo installed, it will linstall the ooRexx script provider. (If you change the
> AOO installation or Java, then run "BSF4ooRexx -> Installation -> Reinstall".)
>
> Note: on Windows you need to make sure to have the same bitness as AOO (assuming 32-bit
> installation) for ooRexx and Java (you can install Java 8 for 32-bit in addition).
>
> Once installed use the "BSF4ooRexx" menu and pick the option "Samples" and open the "index.html"
> file, which gives brief explanations of the samples. Use the link "OOo" to get into the OOo related
> samples (there are many samples that demonstrate how to use OOo writer, calc and impress).
>
> Also, if you program for OOo and like to learn about the definitions of UNO classes, you could use
> the supplied "UNO_API_info.rxo", which can be used from any other programming/scripting language.
> Choose the "BSF4ooRexx" menu then the option "Utilities", go into "OOo/UNO_API_info". Look at the
> file "read-me-UNO_API_info.html" which shows and explains the GUI interface and how to use this
> ooRexx utilitiy from OOo Basic, Java, JavaScript, ooRexx and Python via UNO Dispatch.
>
> ---
>
> To learn about BSF4ooRexx you could go through my PDF slides at
> <http://wi.wu.ac.at/rgf/wu/lehre/autojava/material/foils/>, where
> <AutoJava-BSF4ooRexx-04-OOo-ACE12.pdf> explains OOo programming.
>
> An introduction to ooRexx is given in the slides at
> <http://wi.wu.ac.at/rgf/wu/lehre/autowin/material/foils/>, the PDF slides starting with "ooRexx".
>
> If you have any questions related to ooRexx, BSF4ooRexx and/or UNO/OOo support, please let me know.
>
> Have fun :)

Thanks! That's a lot of useful information.
It will take me some time to read (and understand) it... ;-)

Regards,
   Matthias

>
> ---rony
>
> P.S.: The LO-adjusted provider support will be in the next beta of BSF4ooRexx which I plan for the
> beginning of July.
>
>>> Now, installing that package on her machine the scripts work from outside of LO flawlessly, however
>>> ooRexx does not get registered as another macro language in LO (missing from the "Macro" menu).
>>> After researching this issue for quite some time now, it turns out that LO removed a method in
>>> ClassLoaderFactory and changed the signature of the remaining method by removing the throws clause,
>>> causing a need to compile the script language provider against OOo's ScriptFramework.jar, if the
>>> script provider is to run against OOo, and having the need to compile it separately against LO's
>>> version of ScriptFramework.jar, which is a PITA.
>>>
>>> In the case that there are other script provider programmers hanging around, this is what I did in
>>> order to get a single version that runs also against LO, if there is a need to use
>>> ClassLoaderFactory (maybe in the XScript implementation part):
>>>
>>>          ... cut ...
>>>             
>>>           // instead of: cl = ClassLoaderFactory.getURLClassLoader( metaData );
>>>           // load and run the method dynamically at runtime:
>>>           Class clfClz=Class.forName("com.sun.star.script.framework.provider.ClassLoaderFactory");
>>>           Class smdClz=Class.forName("com.sun.star.script.framework.container.ScriptMetaData");
>>>           Method meth =clfClz.getMethod("getURLClassLoader", new Class<?>[]{smdClz}  );
>>>           cl=(ClassLoader) meth.invoke(null,  new Object  []{metaData});
>>>
>>>          ... cut ...   
>>>
>>> Again, this is just a side note for other script provider implementors who get hit by this LO
>>> pecularity.
>>>
>>> Also: in the "description.xml" deployment file make sure that  the element
>>> "OpenOffice.org-minimal-version has a value "3.4" or higher (cf.
>>> <https://wiki.documentfoundation.org/Development/Extension_Development>), such that the extension is
>>> not regarded as "legacy" by LO.
>>>
>>> In the end, with the above changes, the ooRexx scripting provider again gets accepted as a macro
>>> language for LO.
>>>
>>> The reference remains OOo, which has been working in all other aspects of the Macro menu (run, edit,
>>> making the installed macros available etc.) as per the specifications, whereas LO has some problems
>>> in that area (shared scripts not showing up, listing of the script language in the menu disappears,
>>> if the menu got used, still user macros remain visible and executable).
>>>
>>> ---rony
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>



Re: Just a little side note on the scripting framework ...

Posted by "Rony G. Flatscher (Apache)" <ro...@apache.org>.
Hi Mattias,

On 14.06.2018 22:54, Matthias Seidel wrote:
> Am 14.06.2018 um 20:54 schrieb Rony G. Flatscher (Apache):
>> A friend has LibreOffice installed (due to a better mail-merge-support I understand) and I came up
>> with a script to help her taking advantage of the writer component. The script is written in ooRexx
>> for which I authored an OOo scripting provider that works on OOo, making ooRexx an additional macro
>> language for OOo.
> That's very interesting!
> I know Object Rexx from my times with OS/2 (in fact I am still running
> it in a VM).
That's funny, me too!
;-)

(At one point in time one could create a password protected OS/2 WPS-Folder in ten lines of Object
Rexx code using the SOM - system object model - support! Powerful stuff.)

The source code of IBM Object Rexx got handed over to the non-profit SIG Rexx Language Association
(http://www.rexxla.org), which has been releasing opensource versions under the name of "Open Object
Rexx (ooRexx)" ever since.

I use ooRexx to teach Business Administration students oo-programming from zero knowledge to
programming Windows, MS Office, Linux, MacOSX, OpenOffice, platform independent GUIs (awt, swing,
JavaFX) in *one* semester!

Currently the official 5.0 beta (release quality) version of ooRexx is available for Windows and
Linux from <https://sourceforge.net/projects/oorexx/files/oorexx/5.0.0beta/>.

There is a MacOSX version that includes the latest ooRexx 5.0 beta together with the Java bridge
"BSF4ooRexx" at
<https://sourceforge.net/projects/bsf4oorexx/files/beta/20180312/b4r_600_500_64Bit_macosx-20180324.zip/download>.


> Is your scripting provider available somewhere?
Yes, it is contained in the package BSF4ooRexx, which is a bridge from ooRexx to Java and includes
among other things special support for OpenOffice programming and can be obtained from
<https://sourceforge.net/projects/bsf4oorexx/files/beta/20180312/>. Unzip the archive, go into the
directory "bsf4oorexx/install" and then into "windows" or "linux" and run the "install" script. If
the installer sees OOo installed, it will linstall the ooRexx script provider. (If you change the
AOO installation or Java, then run "BSF4ooRexx -> Installation -> Reinstall".)

Note: on Windows you need to make sure to have the same bitness as AOO (assuming 32-bit
installation) for ooRexx and Java (you can install Java 8 for 32-bit in addition).

Once installed use the "BSF4ooRexx" menu and pick the option "Samples" and open the "index.html"
file, which gives brief explanations of the samples. Use the link "OOo" to get into the OOo related
samples (there are many samples that demonstrate how to use OOo writer, calc and impress).

Also, if you program for OOo and like to learn about the definitions of UNO classes, you could use
the supplied "UNO_API_info.rxo", which can be used from any other programming/scripting language.
Choose the "BSF4ooRexx" menu then the option "Utilities", go into "OOo/UNO_API_info". Look at the
file "read-me-UNO_API_info.html" which shows and explains the GUI interface and how to use this
ooRexx utilitiy from OOo Basic, Java, JavaScript, ooRexx and Python via UNO Dispatch.

---

To learn about BSF4ooRexx you could go through my PDF slides at
<http://wi.wu.ac.at/rgf/wu/lehre/autojava/material/foils/>, where
<AutoJava-BSF4ooRexx-04-OOo-ACE12.pdf> explains OOo programming.

An introduction to ooRexx is given in the slides at
<http://wi.wu.ac.at/rgf/wu/lehre/autowin/material/foils/>, the PDF slides starting with "ooRexx".

If you have any questions related to ooRexx, BSF4ooRexx and/or UNO/OOo support, please let me know.

Have fun :)

---rony

P.S.: The LO-adjusted provider support will be in the next beta of BSF4ooRexx which I plan for the
beginning of July.

>> Now, installing that package on her machine the scripts work from outside of LO flawlessly, however
>> ooRexx does not get registered as another macro language in LO (missing from the "Macro" menu).
>> After researching this issue for quite some time now, it turns out that LO removed a method in
>> ClassLoaderFactory and changed the signature of the remaining method by removing the throws clause,
>> causing a need to compile the script language provider against OOo's ScriptFramework.jar, if the
>> script provider is to run against OOo, and having the need to compile it separately against LO's
>> version of ScriptFramework.jar, which is a PITA.
>>
>> In the case that there are other script provider programmers hanging around, this is what I did in
>> order to get a single version that runs also against LO, if there is a need to use
>> ClassLoaderFactory (maybe in the XScript implementation part):
>>
>>          ... cut ...
>>             
>>           // instead of: cl = ClassLoaderFactory.getURLClassLoader( metaData );
>>           // load and run the method dynamically at runtime:
>>           Class clfClz=Class.forName("com.sun.star.script.framework.provider.ClassLoaderFactory");
>>           Class smdClz=Class.forName("com.sun.star.script.framework.container.ScriptMetaData");
>>           Method meth =clfClz.getMethod("getURLClassLoader", new Class<?>[]{smdClz}  );
>>           cl=(ClassLoader) meth.invoke(null,  new Object  []{metaData});
>>
>>          ... cut ...   
>>
>> Again, this is just a side note for other script provider implementors who get hit by this LO
>> pecularity.
>>
>> Also: in the "description.xml" deployment file make sure that  the element
>> "OpenOffice.org-minimal-version has a value "3.4" or higher (cf.
>> <https://wiki.documentfoundation.org/Development/Extension_Development>), such that the extension is
>> not regarded as "legacy" by LO.
>>
>> In the end, with the above changes, the ooRexx scripting provider again gets accepted as a macro
>> language for LO.
>>
>> The reference remains OOo, which has been working in all other aspects of the Macro menu (run, edit,
>> making the installed macros available etc.) as per the specifications, whereas LO has some problems
>> in that area (shared scripts not showing up, listing of the script language in the menu disappears,
>> if the menu got used, still user macros remain visible and executable).
>>
>> ---rony
>>



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org


Re: Just a little side note on the scripting framework ...

Posted by Matthias Seidel <ma...@hamburg.de>.
Hi Rony,

Am 14.06.2018 um 20:54 schrieb Rony G. Flatscher (Apache):
> A friend has LibreOffice installed (due to a better mail-merge-support I understand) and I came up
> with a script to help her taking advantage of the writer component. The script is written in ooRexx
> for which I authored an OOo scripting provider that works on OOo, making ooRexx an additional macro
> language for OOo.

That's very interesting!
I know Object Rexx from my times with OS/2 (in fact I am still running
it in a VM).
Is your scripting provider available somewhere?

Regards,
   Matthias

> Now, installing that package on her machine the scripts work from outside of LO flawlessly, however
> ooRexx does not get registered as another macro language in LO (missing from the "Macro" menu).
> After researching this issue for quite some time now, it turns out that LO removed a method in
> ClassLoaderFactory and changed the signature of the remaining method by removing the throws clause,
> causing a need to compile the script language provider against OOo's ScriptFramework.jar, if the
> script provider is to run against OOo, and having the need to compile it separately against LO's
> version of ScriptFramework.jar, which is a PITA.
>
> In the case that there are other script provider programmers hanging around, this is what I did in
> order to get a single version that runs also against LO, if there is a need to use
> ClassLoaderFactory (maybe in the XScript implementation part):
>
>          ... cut ...
>             
>           // instead of: cl = ClassLoaderFactory.getURLClassLoader( metaData );
>           // load and run the method dynamically at runtime:
>           Class clfClz=Class.forName("com.sun.star.script.framework.provider.ClassLoaderFactory");
>           Class smdClz=Class.forName("com.sun.star.script.framework.container.ScriptMetaData");
>           Method meth =clfClz.getMethod("getURLClassLoader", new Class<?>[]{smdClz}  );
>           cl=(ClassLoader) meth.invoke(null,  new Object  []{metaData});
>
>          ... cut ...   
>
> Again, this is just a side note for other script provider implementors who get hit by this LO
> pecularity.
>
> Also: in the "description.xml" deployment file make sure that  the element
> "OpenOffice.org-minimal-version has a value "3.4" or higher (cf.
> <https://wiki.documentfoundation.org/Development/Extension_Development>), such that the extension is
> not regarded as "legacy" by LO.
>
> In the end, with the above changes, the ooRexx scripting provider again gets accepted as a macro
> language for LO.
>
> The reference remains OOo, which has been working in all other aspects of the Macro menu (run, edit,
> making the installed macros available etc.) as per the specifications, whereas LO has some problems
> in that area (shared scripts not showing up, listing of the script language in the menu disappears,
> if the menu got used, still user macros remain visible and executable).
>
> ---rony
>
>
>



Re: Just a little side note on the scripting framework ...

Posted by Stephan Bergmann <sb...@redhat.com>.
On 14/06/18 20:54, Rony G. Flatscher (Apache) wrote:
> A friend has LibreOffice installed (due to a better mail-merge-support I understand) and I came up
> with a script to help her taking advantage of the writer component. The script is written in ooRexx
> for which I authored an OOo scripting provider that works on OOo, making ooRexx an additional macro
> language for OOo.
> 
> Now, installing that package on her machine the scripts work from outside of LO flawlessly, however
> ooRexx does not get registered as another macro language in LO (missing from the "Macro" menu).
> After researching this issue for quite some time now, it turns out that LO removed a method in
> ClassLoaderFactory and changed the signature of the remaining method by removing the throws clause,
> causing a need to compile the script language provider against OOo's ScriptFramework.jar, if the
> script provider is to run against OOo, and having the need to compile it separately against LO's
> version of ScriptFramework.jar, which is a PITA.

Running the original ScriptProviderForooRexx.oxt in LO should be fixed 
with <https://gerrit.libreoffice.org/#/c/55871/> "Restore binary 
compatibility for ClassLoaderFactory" (see commit message for details). 
I hope to get that still backported into upcoming LO 6.0.5.

Thanks for reporting!

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org