Allen Pulsifer schrieb:
Hello Joerg,
Thank you for your response. Just to respond further:
The Current/Default distinction in that place was misguided.
That should really be achieved via layering.
I agree with this.
There are other places in OOo where dynamically created keys have such
significance. This is the only way to get mergeable lists of strings.
That statement I can't agree with. The configuration registry is basically
a database. It is not uncommon in database design to use arbitrary key
names. But the name is never used as the value, because the two are
semantically different.
Similarly, in the OpenOffice.org registry, arbitrary key names would be used
where required, with the key value used as the configuration settings. To
get a mergeable list of strings, the key values would be merged, not the key
names.
You are right. In these special schema values are used as keys. That's
more a trick then a good design.
Interesting that there is an outside developer [you sound like somehwere
who knows something about programming .-) ] which analyze the path
settings configuration so deep.
Here some explanations, why the current path configuration was designed
this way ...
I had to fullfill some requirements and the current feature set of our
configuration does not allow so much possible solutions.
a)
As already mentioned by Joerg merging of string-lists (used before) isnt
supported by the configuration. But we had to support layering/merging
of path values. Otherwise an administrator (even an AddOn programmer)
cant realy deal with paths).
An example:
AutoCorrect="$(share)/autocorr;$(user)/autocorr"
An administrator whish to redirect the "user" path to
"/home/allusers/autocorrect". But he cant do that without removing the
share-path or defining it a second time.
Only solution would be:
AutoCorrect="$(share)/autocorr;/home/allusers/autocorrect"
From a database point of view; this design is not normalized.
It contains redundant data.
b)
The only way to reach this goal was using of sets instead of
string-lists. But on the other side the configuration does not know
index based sets. They only allow to design named sets. But what's
happen then ... you have to generate names for every path entry you
whish to add. But you dont have realy usefull names available.
A possible design would be:
<m_1> = <path_value_1>
<m_2> = <path_value_2>
...
<m_n> = <path_value_n>
But then you break a big rule of database design: using of unique keys
as primary keys. Using this design would make it possible to define
set's of paths containing the same value morethen once. Furtehr it
wouldnt be possible for an AddOn programmer to remove specific paths.
He has to know the internal number "m_1" if he wish to remove
"path_value_1". Thats not possible ... because then OOo have to define
and document a lot of unique key numbers which are stable for the future.
c)
So we found the trick to use path values as keys .-)
It does not help for all uses cases (e.g. in case the same path can be
defined using different variables ... as e.g. $(insturl)/share and
$(share)) ... but if everybody follow some rules (e.g. using "most
suitable" variables) it can be more usefull then the old schema.
On the other side: please dont forget - the OOo configuration neverw as
designed to be a database. It does not provide relations nor primary or
secondiary keys. It's normaly a key-value oriented configuration only
... which was might be (realy?) tricky misused .-)
Instead you need to know a list of unspecified key names. You don't
suggest to hardcode "com.acme.supertemplate" into OOo, do you?
I'm not suggesting this. The key names would identify the source of each
path setting, but to OOo, the names would be irrelevant and it would not
need to know them. OOo would enumerate all of the keys under
org.openoffice.Office.Paths/<pathname>/InternalPaths, just like it does now,
except it would concatenate the key values into a path list, instead of
concatenating the key names.
I tested the operation of path configuration in OOo v2.0.4 and wrote up
instructions on how it can be configured by an administrator. Note these
instructions are based on how the path settings have been tested to work,
not how they are intended or documented to work.
Comments are welcome. The instructions are located at:
http://openofficetechnology.com/node/50
I read your documentation ... fine. I miss some details - but in general
it's OK .-)
But here some small corrections from me:
=========================================================================
"Three of these path settings, Backup, Temp and Work, are "single paths"
which means they reference only a single directory. For these settings,
the values in org.openoffice.Office.Paths are ignored, and only the
values in org.openoffice.Office.Common/Path/Default and
org.openoffice.Office.Common/Path/Current are used."
That's not realy true. For those paths the sub properties InternalPath &
UserPath will be ignored and only the property WritePath of the package
org.openoffice.Office.Paths will be used. Additional the value from
org.openoffice.Office.Common/Path/Current (ignoring values of
org.openoffice.Office.Common/Path/Default) are used to detect might
existing user changes on this path. And only in case a difference
between old and new setting was detected the "old" setting will win.
This "migration on demand" was implemented to support old user defined
paths. Currently I'm not so happy with this solution (because it made
some trouble, if e.g. an administrator changed his values NOT inside the
user layer but inisde the share layer ... so it's changes will be lost
now) ... but it's out. On the other side changing the share layer is not
an option in general. Because every patch or upgrade will redesign the
share layer might be. Administrator changes should be done by using
packages installed inside $(share)/uno_packages.
But that's another point.
=========================================================================
"(a) the names (not the values) of the keys under
org.openoffice.Office.Paths/Paths/NamedPath['pathname']/InternalPaths.
These names reference and installation paths and are considered read-only."
These values are not considered read-only. They are flagged as
"mandatory" not "finalized". What's the difference ?
Mandatory entrys can be changed in its values but not removed from the
set. Finalized entrys are read-only related to its values ... but (if
I'm not wrong here) can be removed from the set.
An example:
<node oor:name="Paths">
<node oor:name="Addin" oor:op="fuse" oor:mandatory="true">
<node oor:name="InternalPaths">
<node oor:name="$(progpath)/addin" oor:op="fuse"/>
</node>
</node>
</node>
The "AddIn" entry of the "Paths" set cant be removed. A good idea -
otherwise the AddIn feature will run into some trouble .-)
But it's "values" (including all it's sub properties) can be changed.
So it's further possible to add new InternalPath entries ... or to
define new UserPath entries.
OK - I see a bug here :-)
At least one path value of the AddIn path should exists always.
So "$(progpath)/addin" should be set "mandatory" too.
<node oor:name="Paths">
<node oor:name="Addin" oor:op="fuse" oor:mandatory="true">
<node oor:name="InternalPaths">
<node oor:name="$(progpath)/addin" oor:op="fuse"
oor:mandatory="true"/>
</node>
</node>
</node>
=========================================================================
"The current release of OpenOffice-Enterprise does not allow these
internal values to be changed, but this limitation is intended to be
addressed in a future release."
Mmmhhh ... why we should change that for further releases ? .-)
The problem behind: every path inside path configuration is bound to a
special feature of OOo. (e.g. AddIn, AutoCorrect, UIConfig etcpp).
All these features need at least one (most of them two ... one readable
and one writable path). If e.g. the UIConfig path will be reset to zero
no menu nor any toolbar will be available inside OOo. Further no
accelerator configuration will work. How the office should be useable
then. So OOo try to make a minimum set of paths "fix" ... without
lossing the possibility for the user (or an administrator) to change it
if needed.
Currently I dont see the need to change that excepting fixing bugs then
mentioned before .-)
=========================================================================
Your "merge" algorithm a)...d) must be slightly changed. As already
mentioned before "c) org.openoffice.Office.Common/Path/Current/pathname"
is used as last item [must be d)] ... and it doesnt overwrite always
org.openoffice.Office.Paths/Paths/NamedPath['pathname']/WritePath. Thats
true only for single paths. For multi paths
org.openoffice.Office.Common/Path/Current/pathname is used to extend
org.openoffice.Office.Paths/Paths/NamedPath['pathname']/UserPaths.
=========================================================================
"This limitation that a path setting cannot be completely locked down so
it cannot be edited is intended to be addressed in a future release.
Note however that while individual path settings cannot be completely
locked down, an administrator could prevent editing of all path settings
by disabling the Tools | Options | OpenOffice.org | Paths menu."
This bug was fixed for 2.1. All finalized entries of the
org.openoffice.Office.Paths configuration package will be disabled in
Tools->Options UI also. Flags set inside
org.openoffice.Office.Common/Path wont be recognized !
Small exception: Inside configuration you can use finalize/mandatory
flags at several places in different combinations. The UI doesnt support
all these possible combinations. So it will happen if e.g. UserPath was
set to finalized but WritePath not, the UI will disable the whole path
for editing. This is reasoned by the limited UI of this tab page. Might
be we will redesign this page later and provide more feature here. But I
would be astonished if this will come before 3.0 .-))
Thank you,
Allen
I hope my explanations show you some internal details why the current
path configuration was design this way. It's not finished ... but in
general the right way (my personal opinion).
First of all these changes was made for AddOn programmer. They can
extend the OOo path settings more easy then before. And even
administrators can do that very easy - if they understand how the
configuration work in general. Of course the new schema is more complex
... but the OOo xml configuration is not comparable with simple INI files !
Last but not least my personal optinion ...
From my point of view the OOo configuration shouldnt be changed
manually by an administrator. Why ? An administrator is not a programmer !
Even real OOo programmer has problems to understand the whole feature
set of these configuration.
OOo should provide a set of wizards doing different jobs. But currently
we do not have such wizards and must deal with this situation.
Best Regards
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
