Hi Drew,
Drew Jensen escribió:
Hi Ariel,
I've been following along with your posts - one comment.
About whether an extension supplied database should:
a) be registered
b) show up in the DSB
I think this needs to be narrowly defined. If we are talking about
actual odb files embedded in the oxt file, then I can see an argument
for not doing so. In these cases I would expect that the database is for
use by the extension code and not for direct manipulation by the user.
For example an extension supplies some functionality to the
OpenOffice.org UI and the writer wants to use an odb file for variable
persistence. To be honest I am hard pressed to think of many cases where
the overhead for this would make much sense however.
I agree: I discovered the DataAccess.xcu a long time ago when I
installed the PostgreSQL dedicated driver (drivers use this same
configuration schema). First time I used it: for the "Sample Extension
for Packaging ODB files".
I prefer to use my own configuration schema and register a path using
the %origin% variable. In the other hand, I never ship real embedded
databases with the extensions created for customers: in the simpler case
of 2 PCs reading/writing to the same database is impossible to use an
ODB with HSQLDB embedded, so I prefer MySQL or PostgreSQL, and use
extension only as a easy to install an ODB with only forms (this way I
can update the extension==the forms linking to my repository).
So, besides a case of sample localized databases, I don't see a real use
for embedded databases installed with extensions, because as you say:
The next scenario is the one where the extension is delivering
functionality for a business application. For example a contact
management system, sales force automation, accounting package. In this
case the database is not likely to be supplied as an odb in the oxt
file. More likely the extension will supply a setup function that
creates the database itself, and in this case it would IMO be a mistake
not to register the database and have it available in the DSB. Here then
we have not broken the rule that supplied objects are not modifiable by
the user, as the database object was not supplied but created. Handling
internationalization in these types of applications is nothing new to
OpenOffcie.org and their are commonly accepted ways to do so, although I
am sure best practices will emerge for Base specific instances.
Now there is this special case of an extension that supplies example
databases.
Well, first question is, why is it a special case? Why try to do this
with actual odb files in the extension package at all?
I suppose the reason is reports and forms being in native languages.
Then there is the problem of walking the user through creating forms and
reports with the supplied database, in their language. So - OK, this is
a special case.
I guess that an English speaking user would like to have a sample db
with "John Doe", a Spanish speaking user one with "José Perez", and so
on; that is, not only localized forms/reports but also the data.
Some of these are going to have to be registered, or how will we show
things such as mail merge, adding fields to Calc sheets or Writer
tables, etc.
But again, this is not really a problem. The extension code can register
a database, when it needs to do so for these purposes.
yes, using only custom configuration files you can keep a reference to
any URL using %origin%; so there is no need to register any database at
deploying time of the extension.
So - I would agree that the extension specification and implementation
should not automatically register a supplied odb, but there must be a
simple way to do so within the extensions code when needed. I don't see
how that is not the case already.
Actually now this IS already possible, as I do in the example with the
"localized" database: you store the relative url of the database in an
own configuration file, and then use the singleton theMacroExpander to
get the full URL where the database file is stored.
The question is what to do with the DataAccess.xcu. Will be allowed to
use this for NON-CODE-extensions (the already existing working solution
uses CODE to solve the problem)? Non-code-extensions give the chance to
distribute in a simple way templates, autotexts, ... and databases?
Regards,
Ariel.
--
Ariel Constenla-Haile
La Plata, Argentina
[EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.arielconstenlahaile.com.ar/ooo/
"Aus der Kriegsschule des Lebens
- Was mich nicht umbringt,
macht mich härter."
Nietzsche Götzendämmerung, Sprüche und Pfeile, 8.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
