Files
libreoffice/dbaccess/source/ui/uno/dbinteraction.hxx

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

189 lines
7.7 KiB
C++
Raw Normal View History

2010-10-27 12:33:13 +01:00
/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- */
2012-06-14 17:39:53 +01:00
/*
* This file is part of the LibreOffice project.
*
* This Source Code Form is subject to the terms of the Mozilla Public
* License, v. 2.0. If a copy of the MPL was not distributed with this
* file, You can obtain one at http://mozilla.org/MPL/2.0/.
*
* This file incorporates work covered by the following license notice:
*
* Licensed to the Apache Software Foundation (ASF) under one or more
* contributor license agreements. See the NOTICE file distributed
* with this work for additional information regarding copyright
* ownership. The ASF licenses this file to you under the Apache
* License, Version 2.0 (the "License"); you may not use this file
* except in compliance with the License. You may obtain a copy of
* the License at http://www.apache.org/licenses/LICENSE-2.0 .
*/
#ifndef INCLUDED_DBACCESS_SOURCE_UI_UNO_DBINTERACTION_HXX
#define INCLUDED_DBACCESS_SOURCE_UI_UNO_DBINTERACTION_HXX
#include <cppuhelper/implbase.hxx>
#include <apitools.hxx>
autorecovery: more sophisticated configuration data for interaction handlers 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.
2010-02-01 21:32:33 +01:00
#include <com/sun/star/awt/XWindow.hpp>
#include <com/sun/star/lang/XInitialization.hpp>
#include <com/sun/star/lang/XServiceInfo.hpp>
autorecovery: more sophisticated configuration data for interaction handlers 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.
2010-02-01 21:32:33 +01:00
#include <com/sun/star/task/XInteractionHandler2.hpp>
#include <com/sun/star/lang/XMultiServiceFactory.hpp>
#include <com/sun/star/ucb/AuthenticationRequest.hpp>
2000-10-26 17:08:16 +00:00
#include <com/sun/star/sdb/ParametersRequest.hpp>
#include <com/sun/star/sdb/DocumentSaveRequest.hpp>
namespace com { namespace sun { namespace star { namespace uno {
class XComponentContext;
} } } }
namespace dbtools
{
class SQLExceptionInfo;
}
namespace dbaui
{
// BasicInteractionHandler
typedef ::cppu::WeakImplHelper< css::lang::XServiceInfo
, css::lang::XInitialization
, css::task::XInteractionHandler2
> BasicInteractionHandler_Base;
/** implements an <type scope="com.sun.star.task">XInteractionHandler</type> for
database related interaction requests.
<p/>
Supported interaction requests by now (specified by an exception: The appropriate exception
has to be returned by the getRequest method of the object implementing the
<type scope="com.sun.star.task">XInteractionRequest</type> interface.
<ul>
<li><b><type scope="com.sun.star.sdbc">SQLException</type></b>: requests to display a
standard error dialog for the (maybe chained) exception given</li>
</ul>
*/
autorecovery: more sophisticated configuration data for interaction handlers 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.
2010-02-01 21:32:33 +01:00
class BasicInteractionHandler
:public BasicInteractionHandler_Base
{
css::uno::Reference< css::awt::XWindow > m_xParentWindow;
const css::uno::Reference< css::uno::XComponentContext >
m_xContext;
autorecovery: more sophisticated configuration data for interaction handlers 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.
2010-02-01 21:32:33 +01:00
const bool m_bFallbackToGeneric;
public:
autorecovery: more sophisticated configuration data for interaction handlers 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.
2010-02-01 21:32:33 +01:00
BasicInteractionHandler(
const css::uno::Reference< css::uno::XComponentContext >& rxContext,
autorecovery: more sophisticated configuration data for interaction handlers 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.
2010-02-01 21:32:33 +01:00
const bool i_bFallbackToGeneric
);
// XInitialization
virtual void SAL_CALL initialize( const css::uno::Sequence< css::uno::Any >& rArgs ) override;
autorecovery: more sophisticated configuration data for interaction handlers 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.
2010-02-01 21:32:33 +01:00
// XInteractionHandler2
virtual sal_Bool SAL_CALL handleInteractionRequest( const css::uno::Reference< css::task::XInteractionRequest >& Request ) override;
autorecovery: more sophisticated configuration data for interaction handlers 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.
2010-02-01 21:32:33 +01:00
// XInteractionHandler
virtual void SAL_CALL handle( const css::uno::Reference< css::task::XInteractionRequest >& Request ) override;
protected:
bool
impl_handle_throw( const css::uno::Reference< css::task::XInteractionRequest >& i_Request );
autorecovery: more sophisticated configuration data for interaction handlers 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.
2010-02-01 21:32:33 +01:00
/// handle SQLExceptions (and derived classes)
static void implHandle(
const ::dbtools::SQLExceptionInfo& _rSqlInfo,
const css::uno::Sequence< css::uno::Reference< css::task::XInteractionContinuation > >& _rContinuations);
2000-10-26 17:08:16 +00:00
/// handle parameter requests
void implHandle(
const css::sdb::ParametersRequest& _rParamRequest,
const css::uno::Sequence< css::uno::Reference< css::task::XInteractionContinuation > >& _rContinuations);
2000-10-26 17:08:16 +00:00
/// handle document save requests
void implHandle(
const css::sdb::DocumentSaveRequest& _rParamRequest,
const css::uno::Sequence< css::uno::Reference< css::task::XInteractionContinuation > >& _rContinuations);
/// handles requests which are not SDB-specific
bool implHandleUnknown(
const css::uno::Reference< css::task::XInteractionRequest >& _rxRequest );
/// known continuation types
enum Continuation
{
APPROVE,
DISAPPROVE,
RETRY,
ABORT,
SUPPLY_PARAMETERS,
SUPPLY_DOCUMENTSAVE
};
/** check if a given continuation sequence contains a given continuation type<p/>
2010-12-04 12:33:49 +09:00
@return the index within <arg>_rContinuations</arg> of the first occurrence of a continuation
of the requested type, -1 of no such continuation exists
*/
static sal_Int32 getContinuation(
Continuation _eCont,
const css::uno::Sequence< css::uno::Reference< css::task::XInteractionContinuation > >& _rContinuations);
};
// SQLExceptionInteractionHandler
autorecovery: more sophisticated configuration data for interaction handlers 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.
2010-02-01 21:32:33 +01:00
class SQLExceptionInteractionHandler : public BasicInteractionHandler
{
public:
explicit SQLExceptionInteractionHandler(
const css::uno::Reference< css::uno::XComponentContext >& rxContext
autorecovery: more sophisticated configuration data for interaction handlers 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.
2010-02-01 21:32:33 +01:00
)
:BasicInteractionHandler( rxContext, false )
autorecovery: more sophisticated configuration data for interaction handlers 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.
2010-02-01 21:32:33 +01:00
{
}
// XServiceInfo
DECLARE_SERVICE_INFO();
/// @throws css::uno::RuntimeException
static OUString getImplementationName_Static( );
/// @throws css::uno::RuntimeException
static css::uno::Sequence< OUString > getSupportedServiceNames_Static( );
static css::uno::Reference< css::uno::XInterface >
Create(const css::uno::Reference< css::lang::XMultiServiceFactory >&);
autorecovery: more sophisticated configuration data for interaction handlers 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.
2010-02-01 21:32:33 +01:00
};
// SQLExceptionInteractionHandler
autorecovery: more sophisticated configuration data for interaction handlers 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.
2010-02-01 21:32:33 +01:00
/** an implementation for the legacy css.sdb.InteractionHandler
css.sdb.InteractionHandler is deprecated, as it does not only handle database related interactions,
but also delegates all kind of unknown requests to a css.task.InteractionHandler.
In today's architecture, there's only one central css.task.InteractionHandler, which is to be used
for all requests. Depending on configuration information, it decides which handler implementation
to delegate a request to.
SQLExceptionInteractionHandler is the delegatee which handles only database related interactions.
LegacyInteractionHandler is the version which first checks for a database related interaction, and
forwards everything else to the css.task.InteractionHandler.
*/
class LegacyInteractionHandler : public BasicInteractionHandler
{
public:
explicit LegacyInteractionHandler(
const css::uno::Reference< css::uno::XComponentContext >& rxContext
autorecovery: more sophisticated configuration data for interaction handlers 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.
2010-02-01 21:32:33 +01:00
)
:BasicInteractionHandler( rxContext, true )
autorecovery: more sophisticated configuration data for interaction handlers 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.
2010-02-01 21:32:33 +01:00
{
}
// XServiceInfo
DECLARE_SERVICE_INFO();
/// @throws css::uno::RuntimeException
static OUString getImplementationName_Static( );
/// @throws css::uno::RuntimeException
static css::uno::Sequence< OUString > getSupportedServiceNames_Static( );
static css::uno::Reference< css::uno::XInterface >
Create(const css::uno::Reference< css::lang::XMultiServiceFactory >&);
autorecovery: more sophisticated configuration data for interaction handlers 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.
2010-02-01 21:32:33 +01:00
};
} // namespace dbaui
#endif // INCLUDED_DBACCESS_SOURCE_UI_UNO_DBINTERACTION_HXX
2010-10-27 12:33:13 +01:00
/* vim:set shiftwidth=4 softtabstop=4 expandtab: */