[libreoffice-users] Re: Problems importing an OO database into LO

Am 15.04.2012 17:48, ptoye wrote:
> Well, I seem to have started off quite a discussion. It's interesting that
> Andreas seems to agree with me that OO isn't really for programming. And the
> use of ODF is  extremely important for intercommunicability, a point which
> isn't taken by many MS addicts.
>
> But I'm not trying to use a database to write a form letter - I'm not even a
> fully-fledged business, just a freelance pianist. But I do like to play with
> applications, and occasionally write my own where I can't find a suitable
> share- or free-ware one. And Base just doesn't work well enough - too many
> bugs and I suspect not enough will to drive proper develop,emt - hence
> Andrea's comments on "Potemkin".
The Potemkin village mimics a full featured rural community but it is no 
more than a scenery. When you click through the items of a database 
window, it looks as if you could find everything you need. As soon as 
you kicked all tires you will notice that it does only a small portion 
of what it pretends to do.
Once you downloaded and studied some example databases, you will find a 
true village behind the pretty scenes. It provides everything you need 
to settle down: plain SQL, form design tools, various options to produce 
reports without builders nor wizards. The results not perfect but fairly 
well usable. Once you fully understand this extremely simplified tool 
set you may write some macros or extensions.

> Tom's comment on 4 languages being available is fine, but as the API's so
> impenetrable I feel it would have been better idea concentrate on getting
> one language right rather than four languages wrong! Others are at liberty
> to disagree.
As far as spreadsheets and text documents are concerned, I can find most 
of the objects within a minute.
The languages are all right. Python, Java, JavaScript are not developed 
by the LibreOffice team. The office API is completely independent from 
the language. There is an office API, a mature programming language and 
a few lines of glue code (bridge).
- You need to know a certain API basement right from the start (frame, 
controller, model, services, interfaces, structs).
- Of course you need to know the application on the GUI level very well.
- The language you are using should be familiar to you.
- You should know how to analyse the self-documenting UNO objects. There 
are powerful tools for this. I use to recommend the MRI extension. Even 
this development helper wants to be explored patiently.
As a developer you have to adjust yourself to the application before you 
can adjust the application to your needs. On API level this office is 
radically different from MS Office. This is because "economy" has a 
different meaning in open source context.
Starting with a concrete task imposing a deadline will certainly lead to 
frustration. That's what I learned with VBA 17 years ago. Once I really 
studied a well written VBA book, everything was quick and easy even 
though Office 95 had no code completion.
This API is just like any other complex API. This implies that it is by 
far more abstract (closer to the source code) than VBA which is a thick 
abstraction layer tailored around the respective office application 
within one particular OS. Porting VBA to the MAC succeeded after years 
of hard work because it was never intended to work on a system other 
than WIndows. This office suite does not have any such problems because 
it is not covered by thick sugar coating.



--
For unsubscribe instructions e-mail to: users+help@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted