All database object wizards by now employ XDatabaseDocumentUI. This way, it is ensured that the controller
has the full control over the opened sub components.
Still, other third-party code could use direct access to the document definitions, and open sub documents this way.
This would go unnoticed by the application controller at the moment. I would be possible to fix this, by introducing
broadcasts from the document definitions, listened to by the controller. But as this sounds like a rare case, and
XDatabaseDocumentUI is the preferred way for third-party components, too, such an implementation is deferred to Later ...
Consequently, it does not need to return the created model/controller anymore. This way, the application controller
has full control over its sub components, which didn't work reliably before.
Other wizards (query/form/report) are to follow. For this purpose, they're also to be based on the newly introduced
DatabaseObjectWizard class.
The generic css.task.InteractionHandler implementation in module uui is now able to instantiate "sub handlers", i.e.
components to delegate a request to, based on the type of the request, and some configuration data.
The "old" (and now deprecated) configuration scheme at org.openoffice.ucb.InteractionHandler did not contain type
information, so any handlers registered there were always called when no default implementation for a given request
was available.
The "new" configuration scheme at org.openoffice.Interaction contains UNO type information. That is, a given handler
implementation can declare itself responsible for an arbitrary set of UNO types, and for each of those types, whether
it is also responsible for sub types.
The generic interaction handler implementation uses this configuration data, when it encounteres an interaction
request it cannot fullfill itself, to instantiate a component to delegate the request to.
As with the "old" data, such a component is required to support the css.task.XInteractionHandler2 interface. Also,
if it supports css.lang.XInitialization, then it will be initialized with a name-value pair, the name being
"Parent", the value being the XWindow interface of the parent window for any message boxes.
As an examplary implementation for this feature, the css.sdb.InteractionHandler has been deprecated. Now the
css.sdb.DatabaseInteractionHandler is reponsible for database-related interactions, and the new configuration scheme
is pre-filled with data assigning this responsibility.
Consequently, a lot of places previously creating an css.sdb.InteractionHandler have been modified to create the
default css.task.InteractionHandler.
For the moment, the document only stores and loads itself, as before.
In this course, the AutoRecovery service now delegates the decision whether or not a document
needs to be stored (to the "salvage location") to the document itself, using the new method
XDocumentRecovery::wasModifiedSinceLastSave, superseded the previous E_MODIFIED_SINCE_LAST_AUTOSAVE
flag.
XDocumentRecovery::wasModifiedSinceLastSave has been implemented for SfxBaseModel, yielding the same
behavior as before.
It has also been implemented for database documents, where the implementation is somewhat "sloppy",
in that it returns always <TRUE/> when any of the opened sub components of the document is modified.
