GullFOSS
OpenOffice.org Engineering at Sun
 
Subscribe

Today's Page Hits: 1065

 
Archives
 
« May 2008
SunMonTueWedThuFriSat
    
3
4
6
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
       
Today
Links
Flickr Photos
More Flickr photos tagged with openoffice
Locations of visitors to this page
all tags: accessibility api aqua architecture automated_tests base build calc chart code community compiler cws database development directx download draw eis events export extensions features filter framework graphics gsl gsoc gullfoss i18n import impress installation irc iso26300 java l10n localization mac macros netbeans odf odff ooo ooocon ooxml opendocument openoffice.org patch pdf performance plugin podcast porting qa quality release report sdk snapshot software specification spreadsheet staroffice statistics sun svg toolkit tools usability user-experience vba web wiki writer writerfilter xml
Thursday, 17 Apr 2008
A native Database Driver for MySQL
Frank Schönheit
If you use OpenOffice.org Base to connect to your MySQL database, you probably know that OOo's existing implementation requires you to install an additional driver – either the Connector/ODBC or the Connector/J from the MySQL site. OpenOffice.org itself wraps the external driver, to accommodate to some peculiarities.

Well, this is neither convenient (ever installed an ODBC driver on Unix?), nor efficient, plus prone to losing functionality in the different involved abstraction layers.

Yesterday, our friends over there at MySQL announced a preview release of the MySQL Connector/OpenOffice, a dedicated, native driver which implements OpenOffice.org's database access API, providing access to your MySQL databases.

So, if you're an MySQL and an OpenOffice.org user, this preview release is for you. Get it, try it out, and give us feedback how it worked for you.

The driver comes in the form of an OpenOffice.org extension, to be installed in OpenOffice.org 2.4. For the moment, only versions for Linux and Windows exist, with the final release, this will be extended to all platforms supported by OpenOffice.org itself. Please note you're discouraged from using the extension in the developer snapshots of the upcoming 3.0 release – it might or might not work there, chances for not working are higher the more both release branches diverge.


Find the MySQL Connector/OpenOffice site, having all the above information, and more, at http://forge.mysql.com/wiki/Connector_OpenOffice. Download the connector at http://downloads.mysql.com/forge/openoffice_preview. And do not forget to give us your feedback in Base's mailing list: users@dba.openoffice.org.

tags:

Posted by Frank Schönheit on 17 Apr 2008  |  PermaLink |  Bookmark to del.icio.us Bookmark to del.icio.us |  Digg this Digg this  |  Comments[1]

Wednesday, 17 Oct 2007
Macros in Database Documents
Frank Schönheit

Milestone 680m233 has been finished recently, containing the child workspace basmgr03. This had three consequences (ordered by increasing significance):

  1. The number of my open CWS decreased by 1 to 14. (Hmm. Perhaps next time I feel like doing exorcism I should practice on child workspaces, not on code).

  2. Two bugs have been fixed by passing, which will already slightly improve your "scripting experience" in Base:

    • Issue 81217 describes the cryptic "no script" error message when you (first-time) open a database form which contains macros

    • Issue 76129 describes that you could not bind macros to document events (such as OnLoad) using the usual Tools/Customize functionality

  3. The final (well, hopefully) foundations in the application framework have been laid, so that we now can embark upon Issue 49133: allow to embed macros in database documents like in the other application's documents.

(
In case you wonder why I talk about "Base" vs. "other applications" here: For historical reasons, Base does not use the non-UNO application framework as Writer/Calc/Draw/Impress/Math do, but started implementation from scratch. This decision, dating some years back, had some good and some bad consequences in the last years – one of them being that often enough, we needed to re-implement the other app's functionality, respectively re-factor it so it can be used everywhere. This is what we did with the Basic-IDE in CWS basmgr03.
)

There's still some open questions around this, though. That is, implementing the functionality to embed Basic macros in an ODB file is the first step. Of course you will be able then to execute those macros, to edit them in the IDE, and the like – as you know it from the other applications.

But surely you also want to bind those macros to elements in your forms and macros. Say you want to have a button in a form, which, when pressed, executes a macro located in the embodying database document. Looking at how such binding is done technically, the script is represented as URI, which later is fed into the scripting framework. The URI might be something like vnd.sun.star.script:Standard.Module1.Main?language=Basic&location=document. Note there's the "location=document" parameter: It specifies the function "Main" should be looked up in the module "Module1" in the Library "Standard" in the document's Basic. In contrast, if it should be looked up in the application-wide Basic, the parameter would be "location=application". (Just noticed that chapter 19.6.1 of the Developer's Guide talks about allowed locations being "document", "user", and "share". Seems this is somewhat outdated.)

So, we need to think about how to design a hierarchy of document-local Basic scripts. Should they all be subsumed in the "document" location? That is, if location=document is specified, the macro could be in the form (if there is such a macro), or in the database document which this form belongs to. Or, should a new location type be introduced? location=parentdocument? Doesn't really sounds convincing to me.

Well, for the moment I'm looking forward to start the core implementation. It may be that in a first step, we won't solve the above problem. Even if so, it would still mean you already can embed Basic in .odb files, and you can use it to implement logic in your database application (e.g. by configuring it into the document's toolbar or menu). That alone would be a major step forward, don't you think?

tags:

Posted by Frank Schönheit on 17 Oct 2007  |  PermaLink |  Bookmark to del.icio.us Bookmark to del.icio.us |  Digg this Digg this  |  Comments[2]

Monday, 19 Mar 2007
Applications, Modules, and Usability
Frank Schönheit

If you ever used Base with forms and reports, you most probably already noticed the following: Say you open a form, which comes up with a certain size, work with it, then close it. Afterwards, you open an existing, or create a new text document. Guess what? This text document comes up with the same size as previously your database form. Also, if you previously switched on, say, the Drawing Object Properties toolbar in Writer, it will also be switched on in all your database forms. If you switch it off there, it will also be switched off in your Writer documents. Same for all other toolbars, and for all your menu/toolbar/keyboard customizations – they're all shared between Writer and database forms.

This usually is quite annoying, since the tasks you do in both modules are different, so your working habits probably are different, too. Also – but maybe that's only me – it looks rather unprofessional, doesn't it?

Conceptually, the reason is OpenOffice.org's understanding of modules: Toolbars, menus, keyboard accelerators, as well as window position and size, are attributes of a module (you might look into your installation's share/config/soffice.cfg/modules directory to get an impression). While different applications in OpenOffice.org define different modules – e.g., Calc defines an own module, Writer does, Impress does, plus some more –, database forms are implemented using a somewhat customized Writer, thus they're identified as being the Writer module. Until now.

The child workspace fwkdbdesign01 introduces a concept where modules are separated from applications (thanks to Andreas Schlüns from the framework team for answering our long-year begging!). That is, using the new UNO interface XModule, we can now programmatically change the identifier of a module. Doing so, we can define database forms to be a module different from Writer. As an immediate consequence, all symptoms mentioned above (plus some more, for instance flickering in the Form Design toolbar when initially opening a Writer document or database form) are gone. On a medium term, we are able to better customize form UI to the tasks of database form creation, without affecting Writer. For instance, we could remove (or at least hide from the top-level) all the functionality which is relevant to Writer only, but not to form design.

So, I'm looking forward to this CWS being integrated (it's in QA currently), and I hope I'm not the only one who thinks that this is a change for the better in Base's usability.


tags:

Posted by Frank Schönheit on 19 Mar 2007  |  PermaLink |  Bookmark to del.icio.us Bookmark to del.icio.us |  Digg this Digg this  |  Comments[8]

GullFOSS