How to add a new Resource to working sets?

You might probably seen the working set control in many of the New Wizards. Lets see how to add the control to your wizard.



You don't have to write too much of code to make that happen. The entire UI highlighted above is implemented in the class org.eclipse.ui.dialogs.WorkingSetGroup. Its not an internal class, so feel free to use it. All you have to do is, in your WizardPage.createControl() method, just add this:

workingSetGroup = new WorkingSetGroup(composite, selection, workingSetTypes);

The parameter workingSetTypes is a String[], which tells what are the types of working sets to be shown there. Few of the ids that you might be interested in:

Resource: org.eclipse.ui.resourceWorkingSetPage
Java (JDT): org.eclipse.jdt.ui.JavaWorkingSetPage
Plug-ins and Fragments (PDE): org.eclipse.pde.ui.pluginWorkingSet

To find the entire set of ids available, look at the implementations of the extension point org.eclipse.ui.workingSets (Use Plug-in Registry View)

The above code only gets you the UI. To get the newly created resource added to the working selected by the users, in the performFinish() method of your wizard, add these three lines:

IWorkingSet[] selectedWorkingSets = workingSetGroup.getSelectedWorkingSets();
IWorkingSetManager workingSetManager = PlatformUI.getWorkbench().getWorkingSetManager();
workingSetManager.addToWorkingSets(createdResource, selectedWorkingSets);

Just a 4 lines of code, your New Wizard will look a little consistent with many of the Eclipse Platform Wizards + you can please your Working-Set-savvy user like me :-)

To View or not to View ...

Newbies to Eclipse plugin development will face this dilemma: whether to make xyz a view or an editor. During a training session one of the attendees said, "the choice is simple, if its full of various UI widgets, it would probably better to be a view and if its full of text, then it goes as an editor". The other said, "editors can have multiple intances, but there can be only one instance for a view".

Actually that is not the case. I showed them the Console View (full-of-text) and the Shapes GEF Editor (full of UI). I also showed multiple instances of Console View.

To the workbench, technically there is no much difference between these two - both are IWorkbenchParts. Its more of user experience that they provide. Most of the time, your user will be spending time in viewing and editing the data. It goes natural to give an editor to do all the editing stuff. Views generally do the navigation part and stay as helpers to the editors.

I could see only two differences views & editors:

• Editors contribute to the global action bars, and views to its local action bar.
• In the layout, editors have a special place called editorArea where all the editors will go. Views can go anywhere else, including fast views, detachable ones, etc.

But what about the "saving" thing? Views doesn't support "Save" or "Save As..."?
Well, by default it doesn't support. In case you ever need to do a Save from your view, just make your ViewPart to implement ISaveablePart, you will have the Save & Save As action items will enabled. If your view becomes dirty, workbench will show the * hint in the title. Here is the screen shot of the SampleView implementing ISaveablePart and in dirty state:



Update[3-Jun-2008]
Dave on View versus Editor in RCP
Tom on What is the difference between a view and editor

Schema identifier in the extension points

There are many times you may want to know the id of an extension. Say for instance you want to place your newly created view under the General category. To do that you need to specify the id of the category and the usual way to find out is to browse thru the Plug-in registry view. Given the plethora of plugins & extension points, its not a trivial task.

In case you missed in the New and Noteworthy, 3.4 introduced a wonderful feature that helps you in this - the new Schema Identifier attribute. The implementors of the extension point can simply click the Browse button to get the required id. No need to swim thru the Plug-in Registry view.



If you decide to key in the id directly without using the Browse button and if you make a mistake, PDE will warn you that the id is not available:



If you are an extension point author, to enable this feature, all you have to do is set the attribute type as identifier:



and use the browse button to select the id of the extension point you want:

Adding comments to the generated EMF classes

In the last tip, we saw how to add methods to the EMF generated classes. In this tip, lets see how to add javadoc comments to the methods.

In the generated methods, the default comment would be:



Since the meaning of the 'Pages' attribute isn't clear, we will add some more description there. But how? We can either edit the javadoc and add it there, but then if you were like me who don't want to touch the generated code, here is the way. Its more like the last tip.

Right click the element for which you wish to add the java doc, and add EAnnotation and set the Source to "http://www.eclipse.org/emf/2002/GenModel". Add a details entry to the EAnnotation and set the key to 'documentation' and value to the comment that you want to be generated.



Reload your .genmodel file and generate the code.




As you can see EMF still generates the old comments. This can be changed by dynamic templates, which I'll explain in another tip.

Update[29-May-2008]:

If you delete the source files and then generate the model code, you will find that the comments are appropriately generated:



No need of dynamic templates to do this. I'll be explaining the dynamic templates anyway in another tip!

Adding util methods to the generated EMF classes

We had EMF generated model classes and a Util class with lot of helper methods. Both were exposed to clients as an API. Most of the methods in the Util classes were like:

//API - Util class
Book getBook(Writer writer, String title);

//Customer code
Util.getBook(daveSteinberg, "Eclipse Modeling Framework");

These methods would have been more appropriate in the Writer class itself rather than in a Util class, and it will be more natural to code like:

daveSteinberg.getBook("Eclipse Modeling Framework");

This tip is about how to add such methods in the generated code.

The first way is simple. Just edit the generated java code and add these methods. EMF is smart enough to identify this method and keeps it safe during regeneration of code. But if you were like me, who consider the generated Java files are as good as class files and don't want them checked into the repository, you can follow the second way.

In the eCore Editor for your model, right click the EClass and add a new child EOperation.


Go to the Properties view and specify the name, this will be the name of your method. The EType represents the return type of the method.


If your method has any parameters, then add EParameter children to the EOperation & specify their types and names.



To add the code, add an EAnnotation to the EOperation.


In the properties view, set the Source to "http://www.eclipse.org/emf/2002/GenModel".


Add a details entry to the EAnnotation.



In the properties view set the key to 'body' and value to the code that you want to be generated.



Reload your .genmodel from .ecore and generate the code:

Single column TableViewer and TableColumnLayout

If you have a single column TableViewer (which is commonly used because ListViewer won't show you the images), the single coloumn won't take the entire space. For example if you run the TableViewer snippet, the output is like this:


To get rid of the other spurious coloum that appears on the right, you have to use the TableColumnLayout. Modifying the code to use that:

public Snippet001TableViewer(Shell shell) {

Composite tableComposite = new Composite(shell, SWT.NONE);
final TableViewer v = new TableViewer(tableComposite);
v.setLabelProvider(new LabelProvider());
v.setContentProvider(new MyContentProvider());
MyModel[] model = createModel();
v.setInput(model);
v.getTable().setLinesVisible(true);

TableColumn singleColumn = new TableColumn(v.getTable(), SWT.NONE);
TableColumnLayout tableColumnLayout = new TableColumnLayout();
tableColumnLayout.setColumnData(singleColumn, new ColumnWeightData(100));
tableComposite.setLayout(tableColumnLayout);

}

Remember, the TableColumnLayout should be applied on the composite that holds the Table. And the composite should contain only the table and nothing else. Here is the result: