Frank Schönheit - Sun Microsystems Germany escribió:
(I hope responding to myself is not considered talking to myself ...)
Some more insights ...
(this becomes a habit, it seems)
(ehm ...)
Sadly, *removing* the bibliography's node is not prevented by its
"finalized" attribute. Need to check whether this is intentional.
Looking at the .xsd, it seems this is intentional. Also, I didn't find
any other attribute allowing me to prevent set element deletions. I sent
a mail to [EMAIL PROTECTED] asking whether there is something I overlooked, but
it
seems it is not possible to prevent such deletions.
Over there in [EMAIL PROTECTED], they told me that oor:mandatory is what I need.
And in fact, it works like a charm (when you don't do the same stupid
mistake as I did, letting a cache fool you): Adding this to a node in
the extension's DataAcccess.xcu prevents this node, and thus this DB
registration, from being deleted.
Of course (ehm), the registration UI doesn't care for this ATM, it
somewhat trashes the registration config.
So, I indeed think oor:mandatory at registration entries provided by an
extension is the way to go. Together with a new issue requesting that
this attribute is respected by the registration UI.
Since I have a stripped version of such an extension already (Ariel, the
credits go to your extension, which I stripped down to the very
essentials for this purpose: Am I allowed to use it as bug doc in IZ?),
yes, of course you can use it :-)
I think I'm going to submit an issue.
please do it, you have the whole configuration things more clear than me!
Regards
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]
