1 #*************************************************************************
3 # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
5 # Copyright 2000, 2010 Oracle and/or its affiliates.
7 # OpenOffice.org - a multi-platform office productivity suite
9 # This file is part of OpenOffice.org.
11 # OpenOffice.org is free software: you can redistribute it and/or modify
12 # it under the terms of the GNU Lesser General Public License version 3
13 # only, as published by the Free Software Foundation.
15 # OpenOffice.org is distributed in the hope that it will be useful,
16 # but WITHOUT ANY WARRANTY; without even the implied warranty of
17 # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
18 # GNU Lesser General Public License version 3 for more details
19 # (a copy is included in the LICENSE file that accompanied this code).
21 # You should have received a copy of the GNU Lesser General Public License
22 # version 3 along with OpenOffice.org. If not, see
23 # <http://www.openoffice.org/license.html>
24 # for a copy of the LGPLv3 License.
26 #***********************************************************************/
31 configurationprovider.cxx
32 configurationregistry.cxx
35 UNO service implementations.
40 UNO objects passed to clients.
43 Central singleton that aggregates all data (reads in the XML files, manages
44 modifications and global notifications).
47 localizedpropertynode.cxx
48 localizedvaluenode.cxx
52 Internal representations of data nodes.
65 Modification management.
68 Notification management.
72 Extension manager interface.
86 - A set member can be marked as "mandatory," meaning that a member of that name
87 must always be present in a set.
89 - The above definition implies that calling replaceByName on a mandatory set
92 - The XCU format can contain oor:mandatory attributes on nodes. (The XCS format
93 does not support them. In the registrymodifications file, oor:mandatory
94 attributes should never be needed, as being mandatory cannot be controlled via
95 the UNO API.) The XCU reading code only evaluates the oor:mandatory attribute
96 for set members, and ignores it everywhere else.
98 - Only true sets support mandatory members. A localized property for the "*"
99 locale, though acting much like a set, does not support mandatory members.
101 - The OpenOffice.org Registry Format document claims that group extension
102 properties are implicitly mandatory, but at least the new configmgr code does
103 not treat them like that (i.e., they can be removed again).
105 - For simplicity, setMandatory/getMandatory are available as virtual functions
106 at the base Node, even though they can only make sense for GroupNodes and
107 SetNodes that are set members. The default getMandatory implementation returns
108 NO_LAYER, meaning oor:mandatory is not set to true in any layer. (Returning
109 NO_LAYER simplifies the code, e.g., removeByName does not have to check whether
110 getMandatory is called on a member of a true set to decide whether to forbid
113 - When committing changes (made through the UNO API), the "mandatory" status of
114 inserted nodes must be updated (in case the insert is due to a replaceByName, or
115 the "mandatory" flag was added by a concurrent modification of a lower layer).
116 Also, for to-be-removed nodes, removal is ignored for (newly; due to concurrent
117 modification of a lower layer) mandatory nodes (but still recorded in
118 registrymodifications, so may take effect once the lower layer addition is
119 removed again---whether or not that is a good idea).
122 XcuParser Modification Recording
123 ================================
125 - XcuParser records modifications when reading user layer data
126 (valueParser_.getLayer() == Data::NO_LAYER).
128 - oor:finalized and oor:mandatory attributes cannot be set via the UNO API, so
129 it is assumed that user layer data does not contain them (for one, they are not
130 written by writeModFile; for another, the logic to record modifications expects
131 a locprop(modify,fuse) to be followed by one or more value(fuse,remove), which
132 would not necessarily be true if the locprop were only present in the user layer
133 data to flag it as finalized).
135 - The logic to record modifications considers the top of the XML element stack.
136 In the following list of all possible cases, items marked with an asterisk are
138 ... group(modify,fuse) - group(modify,fuse) - ...
139 ... group(modify,fuse) - set(modify,fuse) - ...
140 ... group(modify,fuse) - *prop(modify,fuse,replace) - value(fuse)
141 ... group(modify,fuse) - *prop(remove)
142 ... group(modify,fuse) - locprop(modify,fuse) - *value(fuse)
143 ... group(modify,fuse) - locprop(modify,fuse) - *value(remove)
144 ... group(modify,fuse) - *locprop(replace) ...
145 ... set(modify,fuse,replace) - group(modify/fuse) - ...
146 ... set(modify,fuse,replace) - *group(replace/fuse) - ...
147 ... set(modify,fuse,replace) - *group(remove)
148 ... set(modify,fuse,replace) - set(modify/fuse) - ...
149 ... set(modify,fuse,replace) - *set(replace/fuse) - ...
150 ... set(modify,fuse,replace) - *set(remove)
151 Legend: "...": zero or more further items
152 "- ...": one or more further items
153 "modify,fuse" etc.: any of those operations
154 "modify/fuse": a modify or a fuse on an existing member
155 "replace/fuse": a replace or a fuse on a non-existing member