<html> <head> <title>Service AdministrationProvider</title> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> <link rel="stylesheet" type="text/css" href="../../../../idl.css"> </head> <body> <div id="adc-idlref"> <a name="_top_"> </a><table class="navimain" border="0" cellpadding="3"> <tr> <td class="navimain"><a href="../module-ix.html" class="navimain">Overview</a></td> <td class="navimain"><a href="module-ix.html" class="navimain">Module</a></td> <td class="navimain"><a href="AdministrationProvider-xref.html" class="navimain">Use</a></td> <td class="navimain"><a href="#devmanual" class="navimain">Devguide</a></td> <td class="navimain"><a href="../../../../index-files/index-1.html" class="navimain">Index</a></td> </tr> </table> <table class="navisub" border="0" cellpadding="0"> <tr> <td class="navisub">Included Services</td> <td class="navisub"><a href="#ExportedInterfaces" class="navisub">Exported Interfaces</a></td> <td class="navisub">Properties' Summary</td> <td class="navisub">Properties' Details</td> </tr> </table> <hr> <table border="0" width="100%" cellpadding="5" cellspacing="3" class="title-table" style="margin-bottom:6pt;"> <tr> <td><p class="namechain"><a href="../../../../module-ix.html" class="namechain">::</a> <a href="../../../module-ix.html" class="namechain">com</a> :: <a href="../../module-ix.html" class="namechain">sun</a> :: <a href="../module-ix.html" class="namechain">star</a> :: <a href="module-ix.html" class="namechain">configuration</a> :: </p> </td> </tr> <tr> <td class="title">service AdministrationProvider</td> </tr> <tr> <td><dl> <dt><b>Description</b></dt> <dd>manages one, or more, complete sets of configuration data for administrative puposes and serves as a factory for objects that provide access to subsets of these shared configurations. </dd> <dd><p>Shared sets of configuration data usually serve to provide defaults, which are used if no individual settings are present. Depending on the data store multiple layers of defaults may be combined with a user-specific layer to make up the final configuration. </p> <p>Many aspects of the supported behavior depend strongly on the underlying data store and on the administrative structures it defines. With some data stores this service also enables access to individual users' configuration data by an administrator. </p> <p>On the other hand, in the simplest model there is only a single layer of default data which is accessible through this service. </p> <p>An implementation is usually obtained from a ::com::sun::star::<a href="../lang/module-ix.html">lang</a>::<a href="../lang/ServiceManager.html">ServiceManager</a>. The arguments passed to ::com::sun::star::<a href="../lang/module-ix.html">lang</a>::<a href="../lang/XMultiComponentFactory.html">XMultiComponentFactory</a>::<a href="../lang/XMultiComponentFactory.html#createInstanceWithContextAndArguments">createInstanceWithContextAndArguments()</a> select the configuration data source. They may also define the scope of administrable data or contain credentials to be used to authorize the administrative access. Missing parameters may be filled in from the context or the environment. </p> </dd> <dt><b>See also</b></dt> <dd><a href="ConfigurationProvider.html">ConfigurationProvider</a><br> Offers the same services and creates the same accessor objects as this service, but accesses the personal configuration. <p>A <a href="ConfigurationProvider.html">ConfigurationProvider</a> provides access to the personal layer of configuration data of the current user context. It should in most cases be used when <em>using</em> the configuration data, although for most contexts a <a href="AdministrationProvider.html">AdministrationProvider</a> can be used as a drop-in replacement. </p> </dd> </dl> <a name="devmanual"> </a><dl> <dt><b>Developers Guide</b></dt> <dd><a href="http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/Config/Connecting_to_a_Data_Source">Config - Connecting to a Data Source</a></dd> <dd><a href="http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/Config/Object_Model">Config - Object Model</a></dd> </dl> </td> </tr> </table> <hr> <a name="ExportedInterfaces"/><table border="1" width="100%" cellpadding="5" cellspacing="0" class="subtitle"> <tr> <td class="subtitle" colspan="2">Exported Interfaces</td> </tr> <tr> <td class="imsum_left">::com::sun::star::<a href="../lang/module-ix.html">lang</a>::<a href="../lang/XMultiServiceFactory.html">XMultiServiceFactory</a></td> <td class="imsum_right"><dl> <dt><b>Description</b></dt> <dd>allows creating access objects for specific views such as subsets and fragments of the configuration. </dd> <dd><p>The parameter <var>aServiceSpecifier</var> passed to ::com::sun::star::<a href="../lang/module-ix.html">lang</a>::<a href="../lang/XMultiServiceFactory.html">XMultiServiceFactory</a>::<a href="../lang/XMultiServiceFactory.html#createInstanceWithArguments">createInstanceWithArguments()</a> supports at least the service specifiers <code>"com.sun.star.configuration.ConfigurationAccess"</code> and <code>"com.sun.star.configuration.ConfigurationUpdateAccess"</code>. </p> <p>Using the first of these service specifiers requests a read-only view of the configuration. The object that is created implements service <a href="ConfigurationAccess.html">ConfigurationAccess</a>. To reflect its <em>element role</em> as root of the view, it implements service <a href="AccessRootElement.html">AccessRootElement</a>. </p> <p>Using the second form requests an updatable view of the configuration. The object that is created should implement service <a href="ConfigurationUpdateAccess.html">ConfigurationUpdateAccess</a>. To reflect its <em>element role</em> which includes controlling updates for the whole view, it implements service <a href="UpdateRootElement.html">UpdateRootElement</a>. <BR />If the root element of the view is marked read-only (as indicated by <b>PropertyAttributes::READONLY</b>), the implementation may either raise an exception or return a (read-only) <a href="ConfigurationAccess.html">ConfigurationAccess</a>/<a href="AccessRootElement.html">AccessRootElement</a> instead. </p> <p>The arguments passed to ::com::sun::star::<a href="../lang/module-ix.html">lang</a>::<a href="../lang/XMultiServiceFactory.html">XMultiServiceFactory</a>::<a href="../lang/XMultiServiceFactory.html#createInstanceWithArguments">createInstanceWithArguments()</a> in parameter <var>aArguments</var> 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::<a href="../beans/module-ix.html">beans</a>::<a href="../beans/PropertyValue.html">PropertyValue</a> or a ::com::sun::star::<a href="../beans/module-ix.html">beans</a>::<a href="../beans/NamedValue.html">NamedValue</a>, so that the parameters can be identified by name rather than by position. </p> <p>What combinations of arguments are supported depends on the service name and on the data store being administered. </p> <p>With both of the standard service-specifiers above, an implementation must accept a single argument named <code>nodepath</code> of type <code>string</code>. 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 <a href="AdministrationProvider.html">AdministrationProvider</a>. 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. </p> <p>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. </p> <p>An implementation may ignore unknown arguments.</p> <p>Some parameters that are commonly supported are described for service <a href="ConfigurationProvider.html">ConfigurationProvider</a>. </p> <p>One notable difference exists for parameter <code>"Locale"</code>. For a <a href="ConfigurationProvider.html">ConfigurationProvider</a> 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 <a href="SetAccess.html">SetAccess</a> 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 <code>locale = "*"</code>. </p> <p>::com::sun::star::<a href="../lang/module-ix.html">lang</a>::<a href="../lang/XMultiServiceFactory.html">XMultiServiceFactory</a>::<a href="../lang/XMultiServiceFactory.html#createInstance">createInstance()</a> 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::<a href="../lang/module-ix.html">lang</a>::<a href="../lang/XMultiServiceFactory.html">XMultiServiceFactory</a>::<a href="../lang/XMultiServiceFactory.html#createInstanceWithArguments">createInstanceWithArguments()</a> had been called using an empty sequence of arguments. </p> </dd> </dl> </td> </tr> <tr> <td class="imsum_left">::com::sun::star::<a href="../lang/module-ix.html">lang</a>::<a href="../lang/XComponent.html">XComponent</a></td> <td class="imsum_right"><dl> <dt><b>Description</b></dt> <dd>allows controlling or observing the lifetime of the configuration. </dd> <dd><p>The owner of the provider may dispose of this object using ::com::sun::star::<a href="../lang/module-ix.html">lang</a>::<a href="../lang/XComponent.html">XComponent</a>::<a href="../lang/XComponent.html#dispose">dispose()</a>. </p> <p>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 <em>snapshot</em> views that have their own copy of the data, if available. </p> </dd> </dl> </td> </tr> </table> <br> <a href="#_top_">Top of Page</a><hr size="3"><p class="copyright" align="center">Copyright © 2008 Sun Microsystems, Inc.</p> </div> <!-- id="adc-idlref" --> </body> </html>
distrib
>
Mandriva
>
2008.1
>
x86_64
>
media
>
main-testing
>
by-pkgid
>
2c50825dd66d0497b96a67f7fab2ee84
>
files
>
1902
