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.
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.
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.
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.
Drew
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
