Hello Frank,
after testing and thinking during the weak end I came to some conclusions.
I think that there are several issues/RFE/features involved in this
subject, so I didn't fill yet any issue: instead I'd like to share my
point here and get your feedback.
What is obviously an issue (type DEFECT) is that the logical name of the
node is displayed in the DSB's tree, insted of the value of the property
"Name".
But all the other things are related to each other, and I am not sure if
include everything in ONLY ONE issue, or report several issues and add
them to the "depends on" (the rules are one problem-one issue, so...)
I reached the conclusion that databases registered by extensions using
the DataAccess.xcu configuration file should not be displayed in the
Options dialog, the user should not be able to change any setting, he
can only remove the extension completely, not modify the register
databases settings.
I came to this conclusion comparing installed databases deployed by an
extension WITH the way extension installation is supposed/planed to work.
Let me quote some things that will make clear that point:
From
http://wiki.services.openoffice.org/wiki/Non-code_extensions#Path_Settings
"[In Dialog "Tools" - "Options" - node "OOo" - leaf "Paths" ] You don't
see the "share/templates" folder here as it is part of the
"InternalPaths" element whose content *intentionally* isn't shown in the
dialog. This element is the *extendable* part of the path setting and it
contains all folders that are added either by the OOo installation
itself or by the installation of an *extension*. As they have been added
by *deployement* they *shouldn't* be controlled by the user, removing
them is a task for those who have added them."
From
http://wiki.services.openoffice.org/wiki/Non-code_extensions#AutoText_Extensions
"There is a tricky part here when you deploy autotext extensions:
currently the autotext GUI allows to save autotexts to arbitrary
locations. This is a bug
[http://www.openoffice.org/issues/show_bug.cgi?id=70410] that needs to
be fixed. Any *changes* *applied* to autotexts in an extension will get
lost when the extension is deinstalled. Extension content is *not*
*meant* to be *changed* *directly*! "
From
http://wiki.services.openoffice.org/wiki/Configuration_schema_path_settings
"The "InternalPaths" element contains all folders that may contain
something and *can't* be *changed* by the users, but they can be
*extended* by UNO packages."
As you see, everything installed by an extension, CAN NOT be directly
changed by the user (examples: the user sees the Templates in the
Templates dialog BUT he can't change the paths nor can see them in the
Option dialogs; extension menu/toolbars are NOT customizable as the
other OOo menu/toolbars)
The user can ONLY delete the extension as a whole (of course he can go
to the respective folder and perform manual changes [delete some
templates, etc.], but this is completely wrong, as some extension can
relay in the contents), he has no control about the extension's contents
individually:
From
http://wiki.services.openoffice.org/wiki/Non-code_extensions#Extension_support_in_the_Configuration_Manager
"Configuration files in OOo extensions create two new layers,
"share/uno_packages" and "user/uno_packages". They lie in between the
default layers, in the obvious *order* of *priority* "share" -
"share/uno_packages" - "user/uno_packages" - "user"."
I understand this as if the "user/uno_packages" has priority over the
"user" layer, that is, extension's configuration affects the user
configuration, but the custom configuration the user can perform CAN NOT
affect/modify the "user/uno_packages" layer.
So, once the user remanes or modifies the datasoruce name in the Options
dialog, in
$USER_DIR/.openoffice.org2/user/registry/data/org/openoffice/Office/DataAccess.xcu
the extension configuration will appear to be removed:
<node oor:name="RegisteredNames">[...]
<node
oor:name="ar.com.arielconstenlahaile.ooo.demo.dbaccess.SampleDatabase1"
oor:op="remove"/>
<node
oor:name="ar.com.arielconstenlahaile.ooo.demo.dbaccess.SampleDatabase2"
oor:op="remove"/>
</node>
Any try to reinstall the extension will be in vain: the databases are
not installed as long as the use the same node identifier.
If I manually remove or comment these lines, there is no need to
reinstall the extension, just restart OOo and the databases will appear
on the DSB tree.
This is obviously an issue, but should I report this or include it in a
more global one?, as is it useless to fix this issue: the databases
shouldn't appear at all on the Options dialog, and the user could not
change any of their settings (at least that's what I could understand
that is planned for extensions deployment).
Other things can be considered enhancements, and are only thoughts:
* as Frank said, the property "Name" should be modified to have an
attribute oor:localized="true": the name of the database should be
localizable: "Biliography" is a name for English, "Bibliographie" for
German, "Bibliografía" for Castillian, etc
* in the aim of localization, the path to the database should also be
localizable (Paths.xcu works in this way); I mean: an extension should
be able to use different databases depending on the user language (this
may be useful a sample database extension with teaching purposes, but
may be for other things too)
* the extension developer should have the choice to make the database
read-only, and even not to make it appear in the data source browser.
As you see I've been testing and thinking about it, but the one
problem-one issue rule gave me seconds thoughts before reporting the
issue/s.
I listen to your comments
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]
