Type: info
Title: more sophisticated configuration data for interaction handlers
Posted by: [email protected]
Affected: api
TaskId: i65597
<http://www.openoffice.org/issues/show_bug.cgi?id=65597>
Effective from: CWS autorecovery
CWS:
<http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=DEV300/autorecovery>
CWS status: new
*Summary*
--------
added new configuration data for custom interaction handlers
*Description*
-------------
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" custom handlers, 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. (This might be
extended in the future, so implementations are urged to really check
the value's name.)
Effectively, this means that extensions which come with an own set of
UNO types can very explicitly register an interaction handler for
those types, without being bothered with all kind of other interaction
requests.
(And implementation-wise, it means that whenever you introduce a new
interaction request type in the future, you're encouraged to check
whether it really needs to be part of the "throw-it-all-in"
implementation in module uui, or can be implemented in a better place,
and hooked into the general handler via configuration data.)
Send feedback to [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
