service ConfigurationProvider in module com::sun::star::configuration:: |
service ConfigurationProvider;
manages one, or more, complete sets of configuration data and serves as a factory for objects that provide access to a subset of the configuration.
An implementation is usually obtained from a
ServiceManager . The default
com.sun.star.configuration.ConfigurationProvider
object, that is
instantiated without using extra arguments, is a one instance service.
Exported Interfaces |
allows creating access objects for specific views such as subsets and fragments of the configuration.
The parameter aServiceSpecifier passed to
XMultiServiceFactory::createInstanceWithArguments()
supports at least the service specifiers
"com.sun.star.configuration.ConfigurationAccess"
and
"com.sun.star.configuration.ConfigurationUpdateAccess"
.
Using the first of these requests a read-only view of the configuration. The object that is created implements service ConfigurationAccess . To reflect its element role as root of the view, it implements service AccessRootElement .
Using the second form requests an updatable view of the configuration.
The object that is created should implement service
ConfigurationUpdateAccess . To reflect its element role
which includes controlling updates for the whole view, it implements
service UpdateRootElement .
If the root element of the view is marked read-only (as indicated
by PropertyAttributes::READONLY ),
the implementation may either raise an exception or return a (read-only)
ConfigurationAccess / AccessRootElement instead.
The arguments passed to XMultiServiceFactory::createInstanceWithArguments() in parameter aArguments specify the view of the configuration that should be created. That is, they determine the subset of elements that can be accessed starting from the returned object. Each element of the argument sequence should be a PropertyValue , so that the parameters can be identified by name rather than by position.
What combinations of arguments are supported depends on the service name.
With both of the standard service-specifiers above, an implementation must
accept a single argument named nodepath
of type string
.
This argument must contain the absolute path to an element of the
configuration. The view that is selected consists of the named element and
all its decendants.
Other arguments can be used to control the behavior of the view. These are different for different implementations. Whether and how they are used may also depend on the configuration store and configuration that were selected when the provider was created.
An implementation must ignore unknown arguments.
Some parameters that are commonly supported are:
"nodepath"
: string
"depth"
: short
"locale"
: Locale Example: In the hierarchy
A - B1 - C1 | - B2 - C2 (localized: de, en, fr, ..) | | | - C3 - D1 | | | | | - D2 - E1 | | | - C4 - D3 - E2 - F1 | | | | | - F2 | | | - C5 | - B3 | - B4 - C6 - D4 - E3
nodepath = "/A/B2"
,
depth = 2
and locale = <Locale for en_US>
would result in the tree fragment
(A-) B2 - C2 (en) | - C3 - D1 | | | - D2 (..) | - C4 - D3 (..) | - C5
"lazywrite"
: boolean
"nocache"
: boolean
XMultiServiceFactory::createInstance() may be unusable. Only an implementation that supports service names that can be used with no further arguments support this method. It should return the same result as if XMultiServiceFactory::createInstanceWithArguments() had been called using an empty sequence of arguments.
allows controlling or observing the lifetime of the configuration.
The owner of the provider may dispose of this object using XComponent::dispose . Note that the default provider is owned by the ServiceManager and should not be disposed of by user code.
Views created by the provider generally refer to data that is managed by the provider. Therefore, disposing of the provider will cause all objects belonging to these views to be disposed of as well. This does not apply to snapshot views that have their own copy of the data, if available.
Copyright 2002 Sun Microsystems, Inc., 901 San Antonio Road, Palo Alto, CA 94303 USA.