The parameter aServiceSpecifier passed to
::com::sun::star::lang::XMultiServiceFactory::createInstanceWithArguments()
supports at least the service specifiers
"com.sun.star.configuration.ConfigurationAccess" and
"com.sun.star.configuration.ConfigurationUpdateAccess".
Using the first of these service specifiers 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
::com::sun::star::lang::XMultiServiceFactory::createInstanceWithArguments()
in parameter aArguments specify the administrative entity for which
data should be administered. In other words they determine the layer to which
changes will apply. They also specify the view of that 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 ::com::sun::star::beans::PropertyValue
or a ::com::sun::star::beans::NamedValue,
so that the parameters can be identified by name rather than by position.
What combinations of arguments are supported depends on the service name
and on the data store being administered.
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. The administrative entity is the default for the
AdministrationProvider. Usually this is the largest entity
encompassing all entities accessible from this instance. In other words this
can be used to influence as global a scope as possible.
Other arguments can be used to select a more specific entity and to control
the behavior of the view. These are different for different implementations
and data stores. Whether and how they are used may also depend on properties
that were selected when the provider was created.
An implementation may ignore unknown arguments.
Some parameters that are commonly supported are described for service
ConfigurationProvider.
One notable difference exists for parameter "Locale". For a
ConfigurationProvider the default behavior usually is to select
the locale set up for the user. But this service by default gets data for all
locales for which data is present. Locale-dependent values in this case are
replaced by a SetAccess using the language names as accessors.
This also allows targetted setting of values for selected locales.
This behavior can be requested explicitly by specifing a special argument
value locale = "*".
::com::sun::star::lang::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
::com::sun::star::lang::XMultiServiceFactory::createInstanceWithArguments()
had been called using an empty sequence of arguments.
