Apache OpenOffice (AOO) Bugzilla – Issue 63706
request for new operation oor:op=fuse
Last modified: 2006-06-13 14:19:05 UTC
Currently the DTD of our configuration format describes the following operations (as xml attributes oor:op=<...>): modify, replace, remove, reset. But in combination with AddOn's it's not quite useable. Because the creator of an AddOn has to know if the underlying configuration layer already has an entry which must be "replaced" or not (then it's must be "modified"). So the creator of an AddOn cant do the right things. As a "workaround" for these, most often the operation "replace" is used. But then it can happen that different AddOn's (changing the same configuration path) will run into conflicts. And it's not clear which of these AddOn's win ... because our PackageManager does not allow to specify an order for installation of AddOn's. So we need a solution to make it possible to "add or modify but not replace" configuration entries also. Please use the attached ZIP files to install it using Tools- >PackageManager. The attached basic macro can be used then to show the merged configuration entries as they are visible at the configuration API at runtime. As a result of this fix both jobs (Job_1 and Job_2) must be visible. Optional it would be nice if this is also true for all events used inside this example. But it's a must for the events "onFirstVisibleTask" / "onUnknownEvent_1". We need an implementation of "fuse" as it's described already on "http://util.openoffice. org/common/configuration/oor-document-format.html".
Created attachment 35303 [details] AddOn 1
Created attachment 35304 [details] AddOn 2
Created attachment 35305 [details] basic script for testing
sb->as: Is this really needed for OOo 2.0.3 (or would OOo 2.0.4 be also acceptable)?
Sorry ... but the described problems occures for a customer addon. So the target OOo 2.0.3 is fix.
.
Due to some other bug, the j1.zip, j2.zip, test.bas test seems to work when running the Basic script in the soffice instance into which the UNO packages were deployed; it consistently fails after soffice restart.
The approach I tried out first to solve this issue's problem was to add a special new flag attribute "fusing-replace" to the "Events" set node in the schema file Jobs.xcs which would have the effect that any "replace" operations on any child nodes of "Events" (within some Jobs.xcu files) would actually be carried out with "fuse" semantics. That way, existing Jobs.xcu files would start to work "right" without having to be modified. However, this does not work, as there are situations where mutliple layers (i.e., multiple Jobs.xcu files) are merged in a schema-agnostic way (i.e., without access to the information in the Jobs.xcs file). unopkg and configimport work that way, and it reflects the registry's design principle that data merging is schema-agnostic. Changing this would be a major rework. Thus, the only reasonable way this issue can currently be solved is by introducing "fuse" as a new operation and using it in new Jobs.xcu files, with the drawback that existing Jobs.xcu files will continue to not work "right."
Created attachment 35540 [details] New AddOn 1
Created attachment 35541 [details] New AddOn 2
Implemented oor:op="fuse", updated <http://util.openoffice.org/common/configuration/oor-document-format.html> (rev. 0.9.9), filed issue 63473 to update DevGuide. Also added UNO constant com.sun.star.configuration.backend.NodeAttribute.FUSE for implementation purposes. From my 03-31-2006 comment, it should be clear that the originally supplied j1.zip and j2.zip will not exhibit the desired behavior after this fix. I supplied new k1.zip and k2.zip that use oor:op="fuse" and should be tested together with test.bas (see my 03-29-2006 comment: run the Basic script after installing k1.zip and k2.zip via "Tools - Package Manger..." and also after restarting soffice). @as: "As a result of this fix both jobs (Job_1 and Job_2) must be visible. Optional it would be nice if this is also true for all events used inside this example. But it's a must for the events 'onFirstVisibleTask' / 'onUnknownEvent_1'." I see no reason to do anything for the other cases here (which use "modify" instead of "replace", and thus fail to register anything, as "modify" means "modify existing; ignore if nothing exists", whereas "replace" means "replace existing; add if nothing exists"); it might be easier for users if the default were "replace" (or "fuse") instead of "modify" in certain places, but this usability issue cannot easily be solved in a backward-compatible way, so we will have to live with it.
In the previous comment, replace "filed issue 63473 to update DevGuide" with "filed issue 64073 to update DevGuide."
verified