Hi Frank,
Frank Schönheit - Sun Microsystems Germany escribió:
Hi Ariel,
an extension may want to ship (embedded) database files (ODB) with it,
to integrate it in the Office modules (DataSourceBrowser == pressing
F4), or simply to load it to the user in some circumstances, or just use
it internally.
..
The following demo extension
http://www.arielconstenlahaile.com.ar/ooo/temp/DatabaseSamplesPackage.oxt
Interesting scenario.
As usual, your feedback is welcome :-)
About the configuration:
- The fact that the DSB displays the logical names of the nodes can only
be called a bug, IMO.
that was my first impression when I saw the DataSourceBrowser with the
node identifier in it
Care to submit an issue for this.
Component and subcomponent? (maybe stupid question, but sometimes I've
no idea where to submit)
Your extension
proves that the behaviour is complete nonsese, since the logical node
name, as you write in your .xcu, must be unique, and thus most
probably not human-readable.
Actually, it seems the value of the "Name" node is nowhere used,
except in the database registration dialog. You even cannot use it in
the database context's getByName (which is different to what you write
in your .xcu)
ups! I wrote it ... but didn't test :-[
It seemed to me obvious that it should work... so what? getByName() must
use the node's logical name?
- The way of retrieving the URL of a data source might also not work as
written in your .xcu: Try renaming one of your registered data
sources, and look into the user-layer's DataAccess.xcu: It seems the
configuration actually deletes the nodes in the extension layer, and
creates new ones in the user layer, with new logical node names.
(Strange, not sure whether this is a configuration bug.)
the data will be stored in
the user data:
$OOo_USER_DIR/user/registry/data/org/openoffice/Office/DataAccess.xcu
and the extension's data (that obviously belongs also to the user):
$OOo_USER_DIR/user/uno_packages/cache/registry/com.sun.star.comp.deployment.configuration.PackageRegistryBackend/registry/data/org/openoffice/Office/DataAccess.xcu
BOTH DO NOT get changed, only the first one.
I wrote:
"WARNING: be aware that the user can edit the name in the Options
dialog, so it is safer to use the URL instead of the name (since OOo
2.0, DatabaseContext :: XNameAccess::getByName() supports an URL besides
a regstired name)."
If the user changes the name, is it "logical" that
/org.openoffice.Office.DataAccess/RegisteredNames changes too and takes
only in account the user's values? ... mmm I tend to think that this is
"logical" and not an issue ...
And also wrote:
"To get the URL you must query OOo configuration nodepath
/org.openoffice.Office.DataAccess/RegisteredNames, get your node by
its name (in this example
ar.com.arielconstenlahaile.ooo.demo.dbaccess.SampleDatabase1),get the
value of the property "Location",and expand it with the MacroExpander
singleton."
BUT you're right: if the user changes the name everything gets erased!
I tested changing ONLY one of the names, this is the result in the USER
layer
($OOo_USER_DIR/user/registry/data/org/openoffice/Office/DataAccess.xcu):
*************************************************************************
<node oor:name="RegisteredNames">
<node oor:name="prueba" oor:op="remove"/>
<node oor:name="Bibliography">
<prop oor:name="Location" oor:type="xs:string">
<value>file:///home/arielconstenlahaile/.openoffice.org2/user/database/biblio.odb</value>
</prop>
</node>
<node oor:name="IT WAS: My Extension Sample Database 2" oor:op="replace">
<prop oor:name="Location" oor:type="xs:string">
<value>vnd.sun.star.expand:$UNO_USER_PACKAGES_CACHE/uno_packages/soDGtl_/DatabaseSamplesPackage.oxt/databases/My_Extension_Sample_Database_2.odb</value>
</prop>
<prop oor:name="Name" oor:type="xs:string">
<value>IT WAS: My Extension Sample Database 2</value>
</prop>
</node>
<node oor:name="My Extension Sample Database 1" oor:op="replace">
<prop oor:name="Location" oor:type="xs:string">
<value>vnd.sun.star.expand:$UNO_USER_PACKAGES_CACHE/uno_packages/soDGtl_/DatabaseSamplesPackage.oxt/databases/My_Extension_Sample_Database_1.odb</value>
</prop>
<prop oor:name="Name" oor:type="xs:string">
<value>My Extension Sample Database 1</value>
</prop>
</node>
<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>
*************************************************************************
* As you see the TWO DBs get removed: but I changed only one. Is this an
issue?
* the config. manager uses for the logical node name and the "Name" node
the same name. Is this an issue too?
The EXTENSION layer does not change
($OOo_USER_DIR/user/uno_packages/cache/registry/com.sun.star.comp.deployment.configuration.PackageRegistryBackend/registry/data/org/openoffice/Office/DataAccess.xcu):
*************************************************************************
<node oor:name="RegisteredNames">
<node
oor:name="ar.com.arielconstenlahaile.ooo.demo.dbaccess.SampleDatabase1"
oor:op="replace">
<prop oor:name="Location" oor:type="xs:string">
<value>vnd.sun.star.expand:$UNO_USER_PACKAGES_CACHE/uno_packages/soDGtl_/DatabaseSamplesPackage.oxt/databases/My_Extension_Sample_Database_1.odb</value>
</prop>
<prop oor:name="Name" oor:type="xs:string">
<value>My Extension Sample Database 1</value>
</prop>
</node>
<node
oor:name="ar.com.arielconstenlahaile.ooo.demo.dbaccess.SampleDatabase2"
oor:op="replace">
<prop oor:name="Location" oor:type="xs:string">
<value>vnd.sun.star.expand:$UNO_USER_PACKAGES_CACHE/uno_packages/soDGtl_/DatabaseSamplesPackage.oxt/databases/My_Extension_Sample_Database_2.odb</value>
</prop>
<prop oor:name="Name" oor:type="xs:string">
<value>My Extension Sample Database 2</value>
</prop>
</node>
</node>
*************************************************************************
I find it "logical" that if the user changes something it gets
registered in /org.openoffice.Office.DataAccess/RegisteredNames
But changing ALL the extension DataAccess config. in the user's side
when he only changes ONE, does not seem so logical.
- for preventing the user from editing registered names, I would have
expected a oor:finalized="true" at the respective configuration node.
(The UI would probably still allow this, since it isn't prepared to
respect the read-onlyness of the underlying configuration.)
However, I wasn't able to get to oor:finalized attribute to work,
neither in the share nor in the user nor in the extension's layer.
Hmm.
... hmmm ... sounds issue-like ... for example I never could make any
kind of constraint work in the configuration
- Trying to connect to the sample DBs in the DSB (or after opening
them from within the DSB) gives some "Invalid argument in JDBC call"
error. Huh? Might be related to the naming issue from the first item,
because connecting is possible when the DB is opened from your sample
menu.
I tried to reproduce it here on Linux SuSe but couldn't
I renamed a registered one (the only that has a table) and both DBs
worked on the DSB... but NOT in the menu any more: as you said, the
config. gets deleted! [I was prudent and used conditional blocks so no
crash takes place]
Care to submit another issue "Cannot connect to database shipped
with extension"?
Can you detail what you've done so I try to reproduce it here?
And may someone in the list can also give a try
Other than that: cool stuff (and yes, the non-cool stuff is on OOo side :().
Well... seems like the "Sample Extension" was too buggy... at least,
getting a localized ODB worked ;-)
I tend to think that nobody had even try to do this (registering a data
source in an extension), and it has never been tested by QA
Nevertheless, this could/should have been included in
http://wiki.services.openoffice.org/wiki/Non-code_extensions
although this wiki is mainly about Paths.xcs/xcu, using
DataAccess.xcs/xcu is also a "Non-code_extensions"
Final conclusion: though my personal opinion is to use add-on config.
and not DataAccess config., I can think about several valid scenarios
where an extension may want to use DataAccess; and technically, it
should work :-(
I will give it a deeper test to find issues!
Bye and thanks,
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]
