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.
When set to <TRUE/>, then an attempt to recover sub documents in the "recovery" folder is made.
In this course, the m_aArgs member of the ModelImpl was replaced with m_aMediaDescriptor, being a NamedValueCollection,
for easier access.
Still some lose ends. Most notably, the current code contains cases for other sub component types,
but has no real implementation - attempting to save/recover those other types will yield multiple
assertions only. Also, recovery of SRB-reports has not been tested, yet, chances are good there's
some work ahead here.
Other known open issues:
- recovering sub components immediately shows them, instead of initially hiding them, and showing
only when the main document window is shown
- the implementation currently is no real session save, which would require saving information about
*unmodified* open sub components (though not their actual content), and restoring them upon
recovery.
- doing an implicit "connect" at the controller of the to-be-recovered database document is a requirement
to actually load the sub components, but might yield problems in case this requires interaction
(e.g. a login). Need to investigate
- the "recovery" storage is not removed from the database document storage after un/successful recovery
- cancelling the recovery of a "modified" database document always suggests to store this doc somewhere
