Hi, I submitted my application via google melange system. The main change that I made is to leave feature of html importing and exporting. I realized that this feature is too hard to do in three months. There will be only plain text and csv import export. Can you give me some feedback? What should I add to my application? What do you think, is this project will be accepted?
WBR Michal 2012/3/26 Rony G. Flatscher (Apache) <[email protected]>: > > On 26.03.2012 17:27, Rob Weir wrote: >> On Fri, Mar 23, 2012 at 10:52 AM, Michał Jaskurzyński >> <[email protected]>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). > >
