platform-update-home/doc/eclipse_plugin_customization.html
Parent Directory
| 
Revision Log
Revision 1.2 -
(download)
(as text)
(annotate)
Fri Jun 21 19:01:42 2002 UTC (7 years, 5 months ago) by droberts
Branch: MAIN
CVS Tags: v20050526, R3_0, R3_1, v20040514, R2_0, v20040219, HEAD
Changes since 1.1: +1 -0 lines
Fri Jun 21 19:01:42 2002 UTC (7 years, 5 months ago) by droberts
Branch: MAIN
CVS Tags: v20050526, R3_0, R3_1, v20040514, R2_0, v20040219, HEAD
Changes since 1.1: +1 -0 lines
Add !DOCTYPE HTML 4.0 Transitional header
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=windows-1252"> <meta name="GENERATOR" content="Microsoft FrontPage 4.0"> <meta name="ProgId" content="FrontPage.Editor.Document"> <title>Eclipse About Dialogs</title> </head> <body> <h1>Eclipse Plug-in Customization</h1> <p>Last revised 19:00 Wednesday May 22, 2002</p> <p>This note describes how an Eclipse-based product can customize any of the plug-ins installed in the product.</p> <h2>What product developers need to know</h2> <p>Any plug-in may choose to expose preferences or internal configuration parameters that are intended to be given product-specific default settings to better tailor that plug-in for the product's operating environment.</p> <p>Product-specific customization is controlled from the product's primary feature through the file named "<code>plugin_customization.ini</code>" located within the primary feature's plug-in (a <a href="http://java.sun.com/j2se/1.3/docs/api/java/util/Properties.html">java.io.Properties</a> format file). Only the primary feature gets to do this; other features have no say. The keys in the <code>plugin_customization.ini</code> file are a property name qualified by the id of the plug-in; for example, the property named "<code>defaultPerspectiveId</code>" in the plug-in with id "<code>org.eclispe.ui</code>" is written "<code>org.eclipse.ui/defaultPerspectiveId</code>". The specified value overrides the <b> default</b> preference value specified by a plug-in. For user preferences, the default override determines the setting that will be used if the user states no preference (or asks to restore defaults). For internal preferences, the default override determines the setting that will be used (since the user has no say).</p> <p>Translatable strings in "<code>plugin_customization.ini</code>" should be extracted into a companion "<code>plugin_customization.properties</code>" file. The "<code>plugin_customization.properties</code>" file is looked for in NL-specific subdirectories within the feature plug-in or fragment thereof.</p> <p>No error is reported for a setting that specifies a non-existent plug-in; the default setting will be overridden in any configuration in which the plug-in is configured, and ignored in all others. </p> <p>The plug-in customization mechanism does not cause plug-in activation; rather, the default setting is applied the first time a plug-in's preference object is accessed.</p> <h2>What product developers do not need to know</h2> <p><b>N.B. The details in this section are not Eclipse platform API, and may change over time. Do not rely on anything described in this section.</b></p> <p>Individual plug-ins often define user preference settings with pre-wired default values.</p> <p>Plug-ins present their user preferences to the user via the workbench. The preferences start out at their pre-wired default values. Any settings that the user changes are saved by the plug-in in its internal preference settings file (located in the plug-in's state area, at <code><<i>workspace</i>>/.metadata/.plugins/<<i>plug-in id</i>>/pref_store.ini</code>). The most recent settings are used when the Eclipse platform is re-launched and the plug-in reactivated.</p> <p>More generally, a plug-in may also have internal preference settings that are never exposed to the user. For example, a plug-in might be pre-configured with a particular URL where the user would be directed for support (or whatever). Internal preference settings are even simpler than user preference settings because there is never a need to save values - everything works from pre-wired defaults.</p> <p>In 1.0, preference settings are supported by UI API (on AbstractUIPlugIn), and is therefore something that is limited to UI plug-ins. There is also an undocumented (and consequently unused) mechanism for overriding these default settings.</p> <p>The changes for 2.0 are as follows: make preference settings available to all plug-ins; provide a simple mechanism that allows a plug-in's preference default values to be externally configured by a product packager through the primary feature; and provide a simple mechanism that allows plug-in preference default values for a packaged product to be externally configured (e.g., by in house teams creating site-specific product installs).</p> <ul> <li>New Core API in Platform Runtime to support preferences. <ul> <li>These are based existing JFace preference and preference store APIs and implementation (based in turn on <code>java.util.Properties</code>.), API and implementation in <code>AbstractUIPlugIn</code>.</li> <li>All default preference settings are expected to be supplied by plug-in itself.</li> <li>Keys are simple name of preference; e.g., "<code>mypref</code>"</li> <li>Plug-in code may set initial default preference values to hard-wired values.</li> <li>Additional default preference value are retrieved from a known read-only file (e.g., "<code>preferences.ini</code>") in the plug-in's root directory (same format as other property settings). <ul> <li>Strings are localized using mechanism like <code>plugin.xml/plugin.properties</code></li> <li>i.e., translatable strings extracted to "<code>preferences.properties</code>" file</li> </ul> </li> <li>Default values from file override defaults hard-wired in code. <ul> <li>Makes it easy for plug-in writers to configure default preference values without changing code.</li> </ul> </li> </ul> </li> <li>Primary feature supplies preference default overrides. <ul> <li> The primary feature is provided by the product packager.</li> <li>This mechanism is for the product packager to customize the plug-ins included in the product.</li> <li>Keys consist of "/'-separated plug-in id and name of preference; e.g., "<code>com.example.myplugin/mypref</code>".</li> <li>A preference default override replaces the default preference value specified by a plug-in.</li> <li>For user preferences, the default override determines the setting that will be used if the user states no preference (or asks to restore defaults).</li> <li>For internal preferences, the default override determines the setting that will be used (since the user has no say).</li> <li>Primary feature's preference default overrides are stored in a properties file with feature (same format as other property settings). <ul> <li>Root file in plug-in (or fragment) for feature is named "<code>plugin_customization.ini</code>"</li> <li>Strings are localized using mechanism like <code>plugin.xml/plugin.properties</code></li> <li>i.e., translatable strings extracted to "<code>plugin_customization.properties</code>" file</li> </ul> </li> </ul> </li> <li>Allow additional preference default overrides to be supplied via the Eclipse command line. <ul> <li>This mechanism is for additional after-market product customization.</li> <li>Allows in-house teams to provide site-specific customization (e.g., URL of team repository).</li> <li>Preference default overrides specified on command line should have precedence over preference default overrides from primary feature.</li> <li>Command line option is "-<code>pluginCustomization</code>" followed by a file name </li> <li>Keys are same as for product packager; e.g., "<code>com.example.myplugin/mypref</code>".</li> </ul> </li> </ul> <p>To summarize, the value of a preference named "<code>mypref</code>" from plug-in "<code>com.example.myplugin</code>" is arrived at as follows:</p> <ol> <li>A user stated preference value for "<code>mypref</code>", if any. (Persisted in a file in the state are plug-in <code>com.example.myplugin</code>.)</li> <li>A default value: <ol> <li>An override value from after-market customization for "<code>com.example.myplugin/mypref</code>", if any.</li> <li>An override value from primary feature for "<code>com.example.myplugin/mypref</code>", if any.</li> <li>A default value for "<code>mypref</code>" as determined by plug-in <code>com.example.myplugin</code>, if any. <ol> <li>A default value for "<code>mypref</code>" from a read-only file found in the root directory of the plug-in, if any. </li> <li>A default value for "<code>mypref</code>" from code in the plug-in, if any.</li> </ol> </li> <li>The default-default value (i.e., 0 for numbers, false for booleans, empty string for strings, etc.).</li> </ol> </li> </ol> </body> </html>
| help@eclipse.org | ViewVC Help |
| Powered by ViewVC 1.0.3 |