incubator-odf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rony G. Flatscher (Apache)" <r...@apache.org>
Subject Re: GSoC: ODF Command Line Tools Application
Date Mon, 26 Mar 2012 19:24:05 GMT

On 26.03.2012 17:27, Rob Weir wrote:
> On Fri, Mar 23, 2012 at 10:52 AM, Michał Jaskurzyński <jaskoola@gmail.com>wrote:
>
>> What do you think about this projekt:
>> http://wi.wu.ac.at/rgf/diplomarbeiten/#bakk_201203a  ? Is it
>> sufficient? Should ODF Command Line Tools be closed or should use this
>> bachelor paper and extend it?
> Hi Michal,  I have not had time to read the entire paper, but I did browse
> through it, especially the code samples.
>
> It looks like it is a REXX wrapper of the ODF Toolkit, with an abstraction
> level similar to our Simple API.     
No, BSF4ooRexx is a wrapper for Java (!), hence the shown ooRexx programs are interacting
directly
with the Java APIs, ie. the ODF Toolkit itself. However the semantics are such of the dynamically
typed, caseless scripting language ooRexx. As a result the same programs run unchanged not
only on
Linux, but also on Windows and/or MacOSX.

In addition (not shown in the Bachelor thesis) there is special support for interfacing ooRexx
directly with OpenOffice in the form of an oxt-extension. This special support brings forward
the
semantics of dynamic types and caselessness to the UNO framework on which OpenOffice is based.
(I am
not aware of a comparable Perl module, Python is currently restricted to the Python shipped
with
OpenOffice.)

The overall aim is to make it easy for professional, but also non-professional programmers
("enduser" resp. "business" programmers) to interact with Java and/or OpenOffice easily in
a
platform independent manner.

Of course, like any other language, one could apply the language ooRexx for creating filters
that
read from stdin and write to stdout (to allow the creation of pipes).

Having said that, still the following applies: there are many ways (and languages) to approach
the
task at hand, and being a pragmatic person, any approach that solves the problem at hand
sufficiently is probably fine ...

---rony

P.S.: Ad "dynamically typed" and  "caselessness": if you look at the few nutshell examples
of the
Bachelor paper, the Rexx programs do not have any type declarations which eases/simplifies
coding
remarkably for (especially for enduser/business) programmers; also, caselessness means that
no
runtime errors are created if the names of methods and fields are not spelled out with the
correct
case, e.g. "odfTable~getCellByPosition(0,4)" has the same effect as "odfTable  ~
GETcellBYpositioN('0',  4)".

Making this behaviour available to (enduser/business) programmers is motivated by the
"human-oriented" paradigm of the Rexx language philosophy and the speed of modern computers,
which
allow for implementations of such principles with a responsiveness to the user, that is totally
acceptable for them. It eases coding for professional programmers alike (especially for creating
scripts).



Mime
View raw message