bundles/org.eclipse.platform.doc.isv/guide/ua_intro_universal.htm - gerrit/platform/eclipse.platform.common - Git at Google

 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
 <html lang="en">
 <head>
 <meta name="copyright" content="Copyright (c) IBM Corporation and others 2000, 2011. This page is made available under license. For full details see the LEGAL in the documentation book that contains this page." >
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
 <meta http-equiv="Content-Style-Type" content="text/css">
 <link rel="STYLESHEET" href="../book.css" charset="ISO-8859-1" type="text/css">
 <script language="JavaScript" src="PLUGINS_ROOT/org.eclipse.help/livehelp.js" type="text/javascript"></script>
 <title>Universal intro</title>
 </head>
 <body>

 <h2>Universal intro</h2>

 <h3>What is the universal intro?</h3>

 <p>
 The universal intro is complete, ready out-of-the-box implementation of intro with a
 pre-defined page structure that all products can rely on (as API). It is a complete
 implementation, including presentation, but without content, and can be used by
 any product.
 </p>

 <h3>Motivation</h3>

 <p>
 Prior to 3.2, the intro framework provided for defining welcome pages with
 unique contribution points or 'anchors'. Other components could provide extensions
 that add content into these anchors. Although this mechanism worked well for closed
 solutions, it is increasingly hard to maintain for large products. Due to the
 'bottom-up' nature of contributions from clients into the welcome pages, it is hard
 to control the final result and resolve conflicting contributions.
 </p>

 <p>
 Take, for example, the provider of a reusable eclipse feature. He/she has
 created a useful feature consisting of a number of plug-ins. The feature can
 take part in several products, each one having its own Welcome implementation.
 There are several problems that the feature provider will face when creating
 Welcome contribution:
 </p>

 <ul>
   <li>
     Since it must contribute into a number of different products, the feature
     must know about the page identifiers for each of the products upfront.
   </li>
   <li>
     It is entirely possible that one of the products will have a Welcome
     implementation that is completely different from what the feature provider
     expects; the contribution will not show up in these products.
   </li>
   <li>
     Even if the products share a common Welcome implementation, the importance
     of the feature (and hence its relative position on the page) is not going to
     be the same. The feature can be one of the most important components in the
     product, or may be ranked as 'See Also'. Nevertheless, the feature provider is
     asked to fully spell out the location on the target page in advance.
   </li>
 </ul>

 <p>
 It is clear that the Welcome contribution of a reusable feature is be much easier
 to develop with the following conditions in place:
 </p>

 <ul>
   <li>
     There is a common Welcome implementation that can be counted on (as a form of API)
   </li>
   <li>
     Delayed target page resolution (so that the decision of the final position
     of the contribution is left to the product assembler)
   </li>
 </ul>

 <h3>Enter universal intro</h3>

 <p>
 The universal intro is based on experience with intro implementations and the
 need to have an implementation in place that contributors can count on. The
 implementation is built using the existing intro framework, and for this reason,
 all existing intro implementation will continue to work and clients will be able
 to switch to the new model according to their schedules. Of course, as long as
 they don't switch, they will not reap the benefits of the new implementation
 such as intelligent content merging, new visual solution etc.
 </p>

 <h3>Benefits</h3>

 <p>
 Some of the benefits of using the universal intro include:
 </p>

 <ul>
   <li>
     Products can simply to point to the universal intro without the need to
     implement an intro from scratch
   </li>
   <li>
     Each product should be able to configure the intro to a certain degree (title,
     branding image, presentation theme)
   </li>
   <li>
     A number of root pages that cover most of the products' needs are be provided.
     The list of pages to show is also configurable
   </li>
   <li>
     The presentation is sufficiently product-agnostic to better suit the
     increasingly componentized world. It works well with both monolithic products
     and 'best of breed' eclipse products assembled with components created by
     different companies
   </li>
   <li>
     End-users can configure the universal intro in a user-friendly way, via the
     preference page
   </li>
 </ul>

 </body>
 </html>
	<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
	<html lang="en">
	<head>
	<meta name="copyright" content="Copyright (c) IBM Corporation and others 2000, 2011. This page is made available under license. For full details see the LEGAL in the documentation book that contains this page." >
	<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
	<meta http-equiv="Content-Style-Type" content="text/css">
	<link rel="STYLESHEET" href="../book.css" charset="ISO-8859-1" type="text/css">
	<script language="JavaScript" src="PLUGINS_ROOT/org.eclipse.help/livehelp.js" type="text/javascript"></script>
	<title>Universal intro</title>
	</head>
	<body>

	<h2>Universal intro</h2>

	<h3>What is the universal intro?</h3>

	<p>
	The universal intro is complete, ready out-of-the-box implementation of intro with a
	pre-defined page structure that all products can rely on (as API). It is a complete
	implementation, including presentation, but without content, and can be used by
	any product.
	</p>

	<h3>Motivation</h3>

	<p>
	Prior to 3.2, the intro framework provided for defining welcome pages with
	unique contribution points or 'anchors'. Other components could provide extensions
	that add content into these anchors. Although this mechanism worked well for closed
	solutions, it is increasingly hard to maintain for large products. Due to the
	'bottom-up' nature of contributions from clients into the welcome pages, it is hard
	to control the final result and resolve conflicting contributions.
	</p>

	<p>
	Take, for example, the provider of a reusable eclipse feature. He/she has
	created a useful feature consisting of a number of plug-ins. The feature can
	take part in several products, each one having its own Welcome implementation.
	There are several problems that the feature provider will face when creating
	Welcome contribution:
	</p>

	<ul>
	<li>
	Since it must contribute into a number of different products, the feature
	must know about the page identifiers for each of the products upfront.
	</li>
	<li>
	It is entirely possible that one of the products will have a Welcome
	implementation that is completely different from what the feature provider
	expects; the contribution will not show up in these products.
	</li>
	<li>
	Even if the products share a common Welcome implementation, the importance
	of the feature (and hence its relative position on the page) is not going to
	be the same. The feature can be one of the most important components in the
	product, or may be ranked as 'See Also'. Nevertheless, the feature provider is
	asked to fully spell out the location on the target page in advance.
	</li>
	</ul>

	<p>
	It is clear that the Welcome contribution of a reusable feature is be much easier
	to develop with the following conditions in place:
	</p>

	<ul>
	<li>
	There is a common Welcome implementation that can be counted on (as a form of API)
	</li>
	<li>
	Delayed target page resolution (so that the decision of the final position
	of the contribution is left to the product assembler)
	</li>
	</ul>

	<h3>Enter universal intro</h3>

	<p>
	The universal intro is based on experience with intro implementations and the
	need to have an implementation in place that contributors can count on. The
	implementation is built using the existing intro framework, and for this reason,
	all existing intro implementation will continue to work and clients will be able
	to switch to the new model according to their schedules. Of course, as long as
	they don't switch, they will not reap the benefits of the new implementation
	such as intelligent content merging, new visual solution etc.
	</p>

	<h3>Benefits</h3>

	<p>
	Some of the benefits of using the universal intro include:
	</p>

	<ul>
	<li>
	Products can simply to point to the universal intro without the need to
	implement an intro from scratch
	</li>
	<li>
	Each product should be able to configure the intro to a certain degree (title,
	branding image, presentation theme)
	</li>
	<li>
	A number of root pages that cover most of the products' needs are be provided.
	The list of pages to show is also configurable
	</li>
	<li>
	The presentation is sufficiently product-agnostic to better suit the
	increasingly componentized world. It works well with both monolithic products
	and 'best of breed' eclipse products assembled with components created by
	different companies
	</li>
	<li>
	End-users can configure the universal intro in a user-friendly way, via the
	preference page
	</li>
	</ul>

	</body>
	</html>