Allen Pulsifer schrieb:
I'm looking over the new Path's configuration and it seems to me the
implementation is awkward and does not follow the usually configuration
paradigm.
In OpenOffice.org v2.0.3 and prior, paths were configured via
org.openoffice.Office.Common/Path/Default and
org.openoffice.Office.Common/Path/Current. This mechanism followed the
usual paradigm of key-value pairs, where the key would tell you what
information you were looking for, and the value would tell you the setting.
So for example, if you wanted to know (or set) the default value for the
template's path, you would look at org.openoffice.Office.Common/Path/Default
and retrieve (or set) the value of the key Template.
The Current/Default distinction in that place was misguided. That should
really be achieved via layering.
This system had several advantages:
(a) If you want to know or set the value for a particular key, you can
access it by key name.
(b) The value for a key could be overridden by a short fragment of XML, at
any configuration layer.
Yes, getting and setting these values is much easier this way. The point
of the change (apparently, I wasn't involved in this) is:
- (Many/all) the affected settings are multi-valued (i.e. lists of
pathes) and were realized as string-lists.
- A string-list really is treated as a simple value by the
configuration. Layer merging replaces the entire list rather than
attempting to merge it. (Yes there are reasons for that.)
- Some of the pathes need to be there for builtin features to work, if
they are taken out of the list those features break.
- Some of these 'internal' are determined at install time and so should
be added to the lists by the layer merge.
- Among the list, at most one path is special in that it is used for
writing user changes. Determining which one that is from its position in
a string-list that users can change arbitrarily is very fragile.
(c) The key-value pairs could be stored in a database, in a traditional way.
The new configuration mechanism for v2.0.4, as documented in
http://specs.openoffice.org/appwide/options_settings/OOoPaths.odt, replaces
the usually key-value pairs with the following:
The configuration settings were moved to org.openoffice.Office.Paths.
Within this tree, there is a node for each path (Template, Dictionary,
Basic, etc.). For each path:
a. There are two key-value pairs, UserPaths and WritePaths, that work as
expected.
The separation addresses the last point above.
b. There is a third subtree, InternalPaths, that contains a set of what
could be considered keys. These keys work completely differently. For the
keys in the InternalPaths tree, the key is the value and the value is
completely ignored.
There are other places in OOo where dynamically created keys have such
significance. This is the only way to get mergeable lists of strings.
For example, for the Template path, InternalPaths
contains a key named "$(insturl)/share/template/$(vlang)". (I've simplified
it slightly by calling this a key; its actually not even a key, it's a group
of type MultiPath that's named "$(insturl)/share/template/$(vlang)" and
forms another subtree that contains a single key "Unused" that is completely
ignored. Thus the name of the group or subtree is what serves as the value,
and both the key within this group and its value are ignored).
That is slightly more complex than needed, because the project team
didn't notice that the configuration supports 'extensible' groups, which
act as sets of simple values. Or else it would have been possible to
make groups with no members work.
This has more than a few disadvantages. First, as far as I can see (but
please correct me if I am wrong) it is not possible to write a short
fragment of XML that overrides the value of this setting, therefore making
true layered configuration impossible.
That is the intent - these keys are required so it shouldn't be easy to
clobber them. OTOH adding to or deleting from that list with a fragment
of XML is now possible (and wasn't before). There even is a feature of
the XML format that would allow completely replacing the contents of
that set - but the implementation of that in OOo is somewhat incomplete
and not active (oor:op='clear').
And you could easily replace the entire 'Templates' node, if it didn't
have an attribute (mandatory='true') that is explicitly meant to prevent
this.
Second, it is not possible to look
this value up or set the value by name, instead, to look the value up, or
set the value, you have to already know the value, i.e., the value is looked
up or set by value and has no independent name.
OOo does not have a raw key-value pair API for its configuration.
Instead you can navigate the hierarchy as objects. The object for the
config node
/org.openoffice.Office.Paths/Pathes/Path['Template']/InternalPath
(yes, that is the correct and complete spelling of the key!) has a
method getElementNames(), which provides the list you are asking for.
XSLT/XPath also has ways to enumerate the children of a known node.
The semantics of combining the three parts into one path-list are also
wrapped into an UNO service, so that is the preferred way of obtaining
that list.
OTOH determining to which path writes should go is much easier (and
unambiguous) now.
The new path configuration could have been implemented using the key-value
paradigm, and maintaining all its advantages while still accomplishing the
same goals, as follows:
InternalPaths would contain a set. Each component that wishes to set an
InternalPath would create a key (also known as a node) within this set using
its own name. For example, the base application would create a key called
org.openoffice.Office.Paths/Template/InternalPaths/org.openoffice.app
An add-on called SuperTemplates by acme.com might create a key called:
org.openoffice.Office.Paths/Template/InternalPaths/com.acme.supertemplates
The value of these keys would be string-lists, just as before. The
multi-layer configuration parser would take these keys and merge them
together into one long string, just like it does now, except that it would
merge the key values, not the key names.
It doesn't merge them into one long string. Ever. You'd get a bunch of
UNO Sequence< String > values, which you'd have to combine yourself in
whatever fashion you need. And before accessing them you also need to
get the list of all the key names.
And yes, with <group oor:extensible='true'> instead of a set it would be
doable this way. Arguably that is cleaner. But it is slightly more
complicated to use.
The advantage of this configuration method is that it maintains the
key-value paradigm. The value of a key can be looked up without already
knowing a value.
Instead you need to know a list of unspecified key names. You don't
suggest to hardcode "com.acme.supertemplate" into OOo, do you?
If an administrator wanted to override the value of
Template path used by the application, he/she could do so with a short
fragment of XML that simply replaces the value of
org.openoffice.Office.Paths/Template/InternalPaths/org.openoffice.app.
Apparently it was intentional that this isn't that easy. (Did I say that
I was not involved in this project?)
And the application apparently uses all the pathes combined,
irrespective of context.
This
XML fragment would look just like every other XML fragment used to configure
OOo. Similarly, for each add-on installed, an administrator could customize
the installation by only knowing the names of the components, not the values
of its paths.
If this is a simple change to make, I would propose it be adopted for v2.1.
At minimum, I believe to the extent possible the key-value paradigm for
configuration should be maintained. There was no reason to break it in
order to allow multiple components to set paths, and by breaking it, some
things that should be simple, both to do and to understand, become much more
difficult.
The dispute appears to be whether these things should be easy to do.
FWIW I agree they should - but not for admins (don't allow them to brea
this), but for packagers/distributors.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
