- Perspectives in Eclipse workbench are visual containers that group related views and editors to accomplish a specific task. - Creating a perspective involves defining an extension in plugin.xml and implementing the perspective class to control initial layout. - Views display data from the domain model and are created by defining an extension point and implementing the view class. - The entry point for an RCP application is a class that implements IApplication to control application execution and create the workbench.

1. Rahul Shukla

2.  Eclipse provides the concept of extension points and extensions
to allow functionality to be contributed to plug-ins by several
other plug-ins.
 Extensions and Extension points are defined via the plugin.xml
file.
 The information about the available extension points and the
provided extensions are stored in a class of type
IExtensionRegistry.
Note:The Eclipse platform reads the extension points and provided
extensions once the plug-in is in the RESOLVED lifecyle status as
defined by the OSGi specification.

3. Plug-in defines extension point- Allows other plug-ins
to add functionality based on the contract defined by
the extension point. The plug-in which defines the
extension point is also responsible for evaluating the
extensions. Therefore the defining plug-in typically
contains the code to evaluate the extensions.
A plug-in provides an extension- This plug-in provides
an extension (contribution) based on the contract
defined by an existing extension point. Contributions
can be code or data.

4. <extension point="org.eclipse.ui.menus">
<menuContribution
locationURI="menu:org.eclipse.ui.main.menu">
<menu label="File">
<command
commandId="org.eclipse.ui.file.exit"
label="Exit">
</command>
</menu>
</menuContribution>
</extension>

5.  A plug-in which defines an extension point must define the extension
point in the plugin.xml file. It also typically contains code to evaluate the
extensions for this extension point to use this information to do
something.
 Extension points are defined via an XML schema file which is referred to
in the plugin.xml file. This XML schema file defines the details and the
contract of the extension point. For example the following shows the
relation to the schema file in the plugin.xml file.
<extension-point id="com.main.view.button" name="MainButton"
schema="schema/com.main.view.button.exsd"/>

6. <annotation>
<appinfo>
<meta.schema plugin="RCPApp" id="com.main.view.button"
name="MainButton"/>
</appinfo>
</annotation>
<element name="button">
<complexType>
<attribute name="id" type="string“ use="required"></attribute>
<attribute name="icon" type="string" use="required">
………..
kind="resource</attribute>
<attribute name="commandID" type="string" use="required">
………..
kind="identifier"
basedOn="org.eclipse.ui.commands/keyBinding/@commandId"/>
</attribute>
</complexType>
</element>

7. public class ButtonExtensionFactory {
private static final String EXT_POINT = "com.main.view.button";
private static List<ButtonData> buttons;
public static List<ButtonData> getButtons() {
buttons = new ArrayList<>();
IExtensionRegistry registry = Platform.getExtensionRegistry();
IExtensionPoint extensionPoint = registry.getExtensionPoint(EXT_POINT);
IConfigurationElement points[] = extensionPoint.getConfigurationElements();
for (IConfigurationElement configElement : points) {
ButtonData bd = new ButtonData();
bd.id = configElement.getAttribute("id");
bd.iconPath = configElement.getAttribute("icon");
bd.cmdID = configElement.getAttribute("commandID");
buttons.add(bd);
}return buttons;}}

8.  Unlike SWT and JFace, which are both general purpose UI
toolkits, the workbench provides the UI personality of the
Eclipse Platform, and supplies the structures in which tools
interact with the user. Because of this central and defining
role, the workbench is synonymous with the Eclipse
Platform UI as a whole and with the main window the user
sees when the Platform is running .
 The workbench API is dependent on the SWT API, and to a
lesser extent on the JFace API. The workbench
implementation is built using both SWT and JFace;
 Java AWT and Swing are not used.

9. Workbench
(0-N) Window
(0-1)Page
(1-N) Prespective
(0-N) Views
(0-N) SWT, JFACE
(0-N) Editors
(0-N) SWT, JFACE

10.  A workbench window can have several separate perspectives, only one of
which is visible at any given moment.
 Each perspective has its own views and editors that are arranged (tiled,
stacked, or detached) for presentation on the screen (some may be hidden at
any given moment). Several different types of views and editors can be open
at the same time within a perspective.
 A perspective controls initial view visibility, layout, and action visibility.
 User can quickly switch perspective to work on a different task, and can
easily rearrange and customize a perspective to better suit a particular task.
 Platform provides standard perspectives for general resource navigation,
online help, and team support tasks. Additional perspectives are supplied by
other plug-ins.

11. Perspectives within the Eclipse workbench are a visual container
for all opened views and editors.
Define the perspective's purpose -- Since the Eclipse
workbench only displays a single perspective at a time, you want to group
logical and functional areas of your application into a unified perspective.
This approach minimizes the need for the user to toggle between different
perspectives to accomplish a particular task. As you work through and
define each perspective's purpose, also keep in mind that a view or editor
cannot be shared between different perspectives. The number of
perspectives that any application will have is largely dependent on the
application's size and complexity.

12. Define the perspective's behavior -- Depending on your
application, a perspective with its collective views, editors, and
actions can be designed to perform distinct functions. For
example, the Java Browsing perspective within Eclipse 3.0 is
designed to provide you various types of information that are
filtered based on a set of selection criteria. This perspective's
behavior filters information for you using a series of consecutive
views. In contrast, the Java perspective is a collection of views,
editors, and actions that give you the ability to edit and compile
Java code. This perspective's behavior is task-oriented and gives
the end user a set of tools to accomplish a particular goal.

13. Creating a perspective is a two-step process.
First, modify the plug-in manifest to include a new extension that uses the
org.eclipse.ui.perspectives extension point.
Second, using the attributes from the new extension point, create a perspective class
<extension point="org.eclipse.ui.perspectives">
<perspective name="Perspective“ class="rcpapp.Perspective"
id="RCPApp.perspective">
</perspective>
</extension>
The <perspective> element has the following attributes:
° id -- This attribute defines a unique identifier for the perspective.
° name -- This attribute defines a name for this perspective, and the workbench
window menu bar uses it to represent this perspective.
° class -- This attribute contains the fully qualified name of the class that
implements the org.eclipse.ui.IPerspectiveFactory interface.

14. public class Perspective implements
IPerspectiveFactory {
public void createInitialLayout(IPageLayout
layout) {
layout.setEditorAreaVisible(false);
layout.setFixed(true);
}
}

15. Views within the Eclipse workbench are visual
containers that allow users to display or navigate
resources of a particular type. As you begin
creating views within your own RCP application,
remember to review the view's purpose before
starting development. Since a view's responsibility
is to display data from your domain model, group
similar types of objects into the view.

16. Similar to other components within Eclipse, to
create a new view, you must define a new
extension within the project's plug-in manifest.
You define views using the org.eclipse.ui.views
extension point. Using the plugin.xml tab of
the plug-in manifest editor within the Google
project, add the following content to begin the
process of creating the views.

17. <extension point="org.eclipse.ui.views">
<view name="View“ class="rcpapp.View"id="RCPApp.view">
</view>
</extension>
 The <view> element has the following attributes:
 id -This attribute defines a unique identifier for the view.
 name -This attribute defines a name for this view, and the
workbench uses it to represent this view.
 category -This optional attribute defines the categories identifiers.
Each category is separated by a '/' and must exist within the plug-in
manifest prior to being referenced by the <view> element.

18.  class - This attribute contains the fully-qualified name of the class that
implements the org.eclipse.ui.IViewPart interface.
 icon -This optional attribute contains a relative name of the icon
associated with the view.
 fastViewWidthRatio - This optional attribute contains the percentage of
the width of the workbench that the view will take up. This attribute
must be a floating point value between 0.05 and 0.95.
 allowMultiple -This optional attribute indicates whether this view allows
for the creation of multiple instances within the workbench.

19. public class View extends ViewPart {
public static final String ID = "RCPApp.view";
public void createPartControl(Composite parent)
{
// Create controls here
}
public void setFocus() {
// control which will be focused when you view
is open .
}
}

20.  Define Prespective Extension
 Add View to the extension
<extension
point="org.eclipse.ui.perspectiveExtensions">
<perspectiveExtension targetID="*">
<view
standalone="true"
minimized="false"
relative="org.eclipse.ui.editorss"
relationship="left"
id="RCPApp.view">
</view>
</perspectiveExtension>
</extension>

21. Demo:RCP Application

23.  Entry Point for and RCP Application
 Extend IApplication.java represent executable
entry points into an application. It can be
configured into the Platform's
org.eclipse.core.runtime.applications extension-
point.
 Controls all aspects of the application's
execution.
 Responsible for creating WorkBenchAdvisor

24. public class Application implements IApplication {
public Object start(IApplicationContext context) {
Display display = PlatformUI.createDisplay();
try {
int returnCode = PlatformUI.createAndRunWorkbench(display, new ApplicationWorkbenchAdvisor());
if (returnCode == PlatformUI.RETURN_RESTART) {
return IApplication.EXIT_RESTART;}
return IApplication.EXIT_OK;
} finally {display.dispose();}}
public void stop() {
if (!PlatformUI.isWorkbenchRunning())return;
final IWorkbench workbench = PlatformUI.getWorkbench();
final Display display = workbench.getDisplay();
display.syncExec(new Runnable() {
public void run() {
if (!display.isDisposed())
workbench.close();}});}}

25.  WorkbenchAdvisor class is responsible for configuring the
workbench that displays when an RCP application executes.
 Developers access to the lifecycle of the generic workbench
 Note that the workbench advisor object is created in advance of
creating the workbench. However, by the time the workbench
starts calling methods on this class, PlatformUI.getWorkbench is
guaranteed to have been properly initialized.
 Resoponsibe for creating windowWorkbenchAdvisor
 Provides default Prespective

26.  CreateWorkbenchWindowAdvisor-Creates a new workbench window advisor for configuring a
new workbench window
 getInitialWindowPerspectiveId-Returns the id of the perspective to use for the initial workbench
window
 initialize -This method is called first before any windows are displayed.
 preStartup - This method is executed second, but is called before the first window is opened.
This method is useful to temporarily disable items during startup or restore.
 postStartup - This method is called third after the first window is opened and is used to re-
enable items temporarily disabled in the preStartup method.
 postRestore - This method is called after the workbench and its windows have been recreated
from a previously-saved state.
 preShutdown -This method is called just after the event loop has terminated,but before any
windows have been closed.
 postShutdown -This is the final method that is called after the event loop has terminated.

27.  Public base class for configuring a workbench window.
 The workbench window advisor object is created in response to a
workbench window being created (one per window), and is used to
configure the window.
 An application should declare a subclass of WorkbenchWindowAdvisor
and override methods to configure workbench windows to suit the needs
of the particular application.
 The following advisor methods are called at strategic points in the
workbench window's lifecycle (as with the workbench advisor, all occur
within the dynamic scope of the call to
PlatformUI.createAndRunWorkbench):

28.  preWindowOpen - called as the window is being opened; use to configure
aspects of the window other than actions bars
 postWindowRestore - called after the window has been recreated from a
previously saved state; use to adjust the restored window
 postWindowCreate - called after the window has been created, either from an
initial state or from a restored state; used to adjust the window
 openIntro - called immediately before the window is opened in order to
create the introduction component, if any.
 postWindowOpen - called after the window has been opened; use to hook
window listeners, etc.
 preWindowShellClose - called when the window's shell is closed by the user;
use to pre-screen window closings

29.  Public base class for configuring the action bars of a workbench
window.
 An application should declare a subclass of ActionBarAdvisor and
override methods to configure a window's action bars to suit the
needs of the particular application.
 The following advisor methods are called at strategic points in
the workbench's lifecycle (all occur within the dynamic scope of
the call to PlatformUI.createAndRunWorkbench):
 fillActionBars - called after
WorkbenchWindowAdvisor.preWindowOpen to configure a
window's action bars

31. Thanks