Digital Paper Napkin

Label Decorators in a Common Navigator Framework viewer

2006-07-19T09:03:00.000-04:00

I just posted these comments elsewhere on label decorators, and thought they might be useful to the general audience for the Common Navigator Framework.

If you check out the org.eclipse.ui.tests.navigator plugin from Eclipse CVS repository, there's a simple example of using a lightweight decorator there. (There are instructions on using Eclipse with CVS, which also documents the repository paths.)

The extension looks like:

<!-- Verify decorator extension: Adds ">>" to Test Items that end in "3" -->
<extension point="org.eclipse.ui.decorators">
<decorator class="org.eclipse.ui.tests.navigator.extension.TestLabelDecorator"
 id="org.eclipse.ui.tests.navigator.threeDecorator"
 label="Items that end in 3 decorator"
 lightweight="false"
 state="true">
<enablement>
 <objectclass
     name="org.eclipse.ui.tests.navigator.extension.TestExtensionTreeData" />
</enablement>
</decorator>
</extension>

And the type must implement ILabelDecorator:

import org.eclipse.jface.viewers.ILabelDecorator;
import org.eclipse.jface.viewers.ILabelProviderListener;

public class TestLabelDecorator implements ILabelDecorator

There's an FAQ on label decorators, as well as an article with more detail. Right off, I don't think this topic would merit a full article in this series on contributing label decorators to Common Navigator Framework viewers, so if you think there's enough need out there, chime in!

Boxing and Bourbon - Scapa, Kentucky Spirit, and Ol' Pappy!

2006-07-17T21:43:00.000-04:00

When I started this blog, I said I'd review a scotch or bourbon and a cigar from time to time. I've been churning out CNF articles for the last couple of months and I've neglected that part of the original vision for the blog. But I digress.

Over the last couple of weeks, I've had the chance to enjoy some very tasty beverages. But before I get into that, I'd like to throw out a much belated thanks to the good folks over at Scapa Technologies. At the last EclipseCon, through the bequest of a friendly WTP PMC member, I was fortunate enough to end up with one of the bottles of Scapa 14yr that they brought along. Scapa is an Orkney Islands scotch that's hard to come by in my neck of the woods. I've had the Scapa 12yr before though, and I have to say that it goes great with a good steak -- particularly a ribeye or prime rib. I've always thought it had a nice honey with a hint of vanilla flavor that's different from the more peaty or smokey scotches. It also goes very well with any medium to full bodied cigar.

At least once or twice a week, I catch up with a friend of mine to catch the fights. The past two weeks have been pretty decent boxing matches, but particularly good for bourbon.

If you're looking to try something a little more full bodied than your average bourbon, without quite the taming that an aged bourbon undergoes, check out the Wild Turkey Kentucy Spirit. The flavor is full enough to be compared to the 10 year Wild Turkey Russell Reserve, but still has a nice ruggedness like a straight up Wild Turkey 101. Each Kentucky Spirit bottle is individually labeled with the warehouse, row, barrell, and date of bottling. Each barrell is hand selected by Jimmy Russell, the master distiller of Austin Nichols.

And finally, the week before last, I was lucky enough to try Some Pappy Van Winkles 20yr. This really was a cut above just about any other bourbon that I've had. It's very smooth, but still has a nice little afterburn. I would describe the flavor as having the hint of butterscotch on the aftertaste, which was unique among the bourbons I've had before. This is another of the many fine tasty beverages not available in my local area, although there is one savvy local establishment that carries the Pappy Van Winkle's 15yr, which is great -- but the extra 5 years on the 20yr really makes a difference!

Well, I think that's about all I have to add on this topic for now. In my next Boxing and Bourbon post, I'll cover a few cigars that I've had recently -- both new and old favorites.

* The image of Pappy Van Winkles was linked to from their website. The other two images were my own.

PDF versions now available!

2006-07-16T19:00:00.000-04:00

Some readers have requested PDF versions of the CNF articles. After some investigation of some pointers from Brian Fitzpatrick, I decided to go with PrimoPDF. The content of each article is roughly unchanged, excluding some minor formatting adjustments.

I have attached versions of the existing articles below, as well as comments to the original posts.

Building a Common Navigator Framework Viewer

Part I: Defining the Viewer (*.pdf) (original post)

Part II: Adding Content (*.pdf) (original post)

Part III: Configuring Menus (*.pdf) (original post)

Part IV: Object Contributions (*.pdf) (original post)

Part V: Action Providers (*.pdf) (original post)

What does the Common Navigator Framework help me do? (*.pdf) (original post)

Once a few more of the foundations of building CNF viewers are covered, I will integrate these articles into a more coherent organization and prepose them as Eclipse Corner articles. The links above point to attachments on Bug 143127: [CommonNavigator] Examples.

It takes a village

2006-07-13T22:32:00.000-04:00

With some great help from the community, part of the series is no longer necessary. Aashish Patil has prepared an article on rendering Non-Resource content in a Common Navigator Framework viewer.

Anybody else want to step in to help?

For anyone that decides to jump in, feel free to either build the example in the org.eclipse.ui.examples.navigator plugin in the Eclipse CVS repository (check out as anonymous, generate a patch, and attach it to bug 143127). There are also some instructions on using Eclipse with CVS, which also documents the repository paths.

Or you can just build a complete example as Aashish did, and then attach it to bug 143127: [CommonNavigator] Examples as a zip file to make it available to the community.

Thanks Aashish!

Response to comments and status on upcoming articles

2006-07-12T21:23:00.000-04:00

When responding to a few of the latest comments on Part IV, it seemed like it made the most sense to just write a quick post. I hope to have Part V ready by the end of the week -- Monday at the latest.

I've been busy with a few other activities over the last few weeks -- one of which was a great vacation, and now I'm back.

The following quotes are snippets of comments from Part IV, I've copied them here for context.

"You may want to mention (or show an example implementing) IObjectActionDelegate."

I'll make a note for a short example of using IObjectActionDelegate just after Part V. My guess is there are other tutorials around for that topic (outside of the CNF context), so I may be able to find them and just post a link.

"It looks to be a simple task to hook up the CNF to our virtual file system that accesses about 33 TB of disk. I had a prototype up and running in less than an hour."

The filesystem example sounds pretty cool. I would hate to see how long an "expand all" type operation would take for 33TB though. Are you planning to use or provide "Go Into" support? (Which is not supported by the base framework, but I know of other clients that have implemented it).

"How do I sort the root nodes?"

I'll make sorting the topic of the next article in the series. The algorithm for sorting in a generic context is kind of interesting, so it would merit an explanation better than the one available in the slides anyway.

"At what point should I starting doing the work of building my nodes for my common navigator? I wanted to tie in the IProgress monitor and jobs to prevent blocking."

I have an article and example prepared for deferred loading of model data. For various reasons, the base framework doesn't support this natively. For clients that want to roll your own solution, there are a couple of points to be aware of, but it's not too complex. Deferred model loading can be used to offload expensive calculation out of the UI thread -- you could choose to pop a progress service dialog (which I would tend to discourage), but running the model loading operation in a Job, which shows progress in the Progress View is a great way to keep the UI responsive for the user. Would there be enough interest to make deferred model loading Part VII of the series?

"Secondly at what points are the methods in the content provider called? ... Will I need to refresh parts of my navigator during runtime?"

You have to call refresh() or update() on the viewer as necessary. You can implement fine-grained calls to add()/remove() to update the viewer; it's up to you to decide what makes the most sense for your scenario. You will have a reference to the viewer in the inputChanged() method on the content provider. You can remember the reference and generate events as necessary. Take a look at the org.eclipse.ui.examples.navigator plugin and specifically at the PropertiesContentProvider's implementation of inputChanged() and it's visit() method to refresh files as they change.

So in summary, I'm tentatively planning the following articles:

Part V : Action Providers
Part VI: Sorting
Part VII: Deferred model loading
Part VIII: Non-resource content

Building a Common Navigator based viewer, Part V: Action Providers

2006-06-18T19:32:00.000-04:00

Thought is the blossom; language the bud; action the fruit behind it.
-- Ralph Waldo Emerson

Overview

Action Providers provide a means to configure the retargetable actions and programmatically configure the context menu in a Common Navigator Framework viewer. In this article, we'll take a look at what an ActionProvider can do, and how to implement one for our Example View.

Action Providers are useful for cases where you have to perform some computation before you can decide what items to add to a menu or you need to adjust the retargetable actions to ensure that user keystrokes are handled properly (like Cut(Ctrl+x)/Copy(Ctrl+c)/Paste(Ctrl+p)/Delete(Delete)).

Creating our Action Provider implementation

In other posts, we started with the XML configuration for the extension. For this article, we'll start from the code.

First, we'll create our Action Provider class, which must extend org.eclipse.ui.navigator.CommonActionProvider.

Our class must define a no-argument constructor so that instances may be created from our extension.

In our init() method, we verify that we are executing inside of a workbench part (opposed to a dialog), and then create the OpenAction, which takes the workbench page and a selection provider in its constructor. The ICommonActionExtensionSite provides access to several things that a CommonActionProvider might need. I'll refer you to the Javadoc API for more details here.

Common Navigator viewers are capable of being enclosed in dialogs. Thus, a reference that is a subclass of ICommonViewerSite is supplied by default from the ICommonActionExtensionSite. If your Action Provider is used by a viewer in a dialog, you cannot cast down to access the workbench page, since it is not available. In general, most Action Providers make assumptions that they are only used in workbench parts.

The fillActionBars() method can be used to configure retargetable actions. A retargetable action is an instance of org.eclipse.ui.actions.RetargetAction with a unique identifier. The workbench registers many of these actions by default (see org.eclipse.ui.IWorkbenchActionConstants).

There is currently only one retargetable action defined by the Common Navigator Framework (CNF), org.eclipse.ui.navigator.ICommonActionConstants.OPEN. (But of course, you can register an action for any of the identifiers in IWorkbenchActionConstants). In the CNF, a RetargetAction with the ICommonActionConstants.OPEN identifier is executed each time an open event occurs on a viewer. If no action is registered when an open event occurs on a node in the viewer, the node's expanded state is toggled.

In our example, we are going to register our OpenAction if it is enabled (we'll take a look at how this is determined shortly).

Note: If this action provider is used in a dialog context, the openAction would be null because we only initialize it if we receive an ICommonViewerWorkbenchSite, so if you need your Action Provider to be robust enough for either workbench parts or dialogs, be that either all of your action fields are initialized or you check for null.

The fillContextMenu() method uses the ICommonMenuConstants to make sure that the openAction is positioned correctly in the menu.

Our openAction is fairly simple. The contents of the run() method are unimportant for this example, but you can take a look at the example in the repository. The constructor and the isEnabled() method are shown here. The constructor remembers the references we pull from the ICommonViewerWorkbenchSite.

Adding our Action Provider to our viewer

Now let's take a look at our extension definition. Here we nest the actionProvider under our navigatorContent element in our org.eclipse.ui.navigator.navigatorContent extension. Remember that we constructed the rest of this extension in previous articles.

The actionProvider element specifies an identifier and our implementation class.

Since we have nested the actionProvider element under our navigatorContent extension, the existing viewerContentBinding that binds our content extension to our viewer also absorbs our action provider.

Furthermore, the menu options and retargetable action configuration will only be available if our extension is active. If the user turns off our extension, then they will not need these actions, the CNF will not invoke them.

Alternatively, we could expose our actionProvider independently and use a viewerActionBinding to bind the Action Provider to our viewer. In this case, the action provider will be available, even if our content extension is not.

The final example view should appear like the following. When the "Open Property" action is selected, the property file will be opened and the property name will be selected.

Summary

In this article, we have seen why an Action Provider does, walked through how to implement an Action Provider, and bound the Action Provider to our viewer.

In our next article, we'll take a look at sorting our properties elements.

Building a Common Navigator based viewer, Part IV: Object Contributions

2006-06-18T19:30:00.000-04:00

Action may not always bring happiness, but there is no happiness without action.
-- Benjamin Disraeli

Overview

In the last post, we discussed how to configure the popup menus for a Common Navigator instance. As we saw, a Common Navigator can declare all of its menu insertion points through the org.eclipse.ui.navigator.viewer extension point and indicate whether contributions to the org.eclipse.ui.popupMenus extension point should be honored. The declarative menu configuration serves the dual purpose of avoiding programmatic configuration of the menu structure, and documenting the menu structure for potential extenders.

We also briefly talked about the two ways that contributors can tap into a menu. The first was through org.eclipse.ui.popupMenus, which allows you to add menus throughout the workbench, and the second was through org.eclipse.ui.navigator.navigatorContent, which is specific to the Common Navigator framework. We will cover ...popupMenus in this article, and ...navigatorContent in the next.

As always, you can find the full source for this example in the org.eclipse.ui.navigator.examples plugin from the Eclipse CVS repository. There are also some instructions on using Eclipse with CVS, which also documents the repository paths.

With that out of the way, let's dive into the example.

Adding a Delete Property action through org.eclipse.ui.popupMenus

Recall that for this series of articles, we are rendering a simple model of a properties file.

Now we are going to add a Delete Property action that allows a user to select a property from the listing above and remove it.

Open the Plug-in Manifest Editor by double clicking the plugin.xml file in your plugin project. If you're not quite sure what this means, check out Part I of this series.

On the Extensions tab, select Add... and choose org.eclipse.ui.popupMenus. If you don't see this option listed, uncheck "Show only extension points from the required plugins". If you haven't already added org.eclipse.ui as a dependent plugin, this will take care of that for you.

Now select the entry created in the list ("org.eclipse.ui.popupMenus"), right-click and choose "objectContribution". Then, right-click again and choose "action".

An objectContribution can declare menus (submenu extensions of the popup menu) and actions. The extension is fairly verbose to help optimize plugin loading. That is, the extension declares enough information that the actual class (and therefore the plugin) doesn't need to be loaded to render the menu. If the user never selects the action, then the plugin needn't be loaded.

In particular, the extension declares the menu label, the menu icon, and a tooltip among other things. The extension also declares the menubar path (recall we described the values for insertion points in Part III).

Use the values from the following diagram to configure the action element. You can enter the values on the Extensions page, or flip over to the plugin.xml tab and fill it in by hand.

There's a few things we should discuss here.

First is the objectClass, which declares that we are interested in ...PropertiesTreeData. Recall from Part II that we defined a simple object model to represent the name=value pairs in a property file. To delete these items, we want our action to enable on instances of our model.

The class attribute specifies a subclass of org.eclipse.ui.actions.ActionDelegate. The implementation of DeletePropertyAction.run(IAction) has some boilerplate for robustness, but the important part is as follows:

ActionDelegate declares a selectionChanged(IAction, ISelection) method that is updated when the selection in the viewer changes. We override this method to remember the selection, so that in the event that the user selects the menu option, we know what item they clicked on.

Summary

And that's all there is to it.

Now you should feel comfortable experimenting with adding more actions to the popup menu, as well as adding submenus. Be sure to check out the menu element (accessible in the same way you found action earlier). If you use the Extensions tab, all of the available attributes will be accessible to you, and remember you can use the right-click menu to create sub elements.

In this article we covered the basics of contributing an action to our example viewer through the org.eclipse.ui.popupMenus extension point. In the next article, we'll cover how to programmatically configure the menu using an extension of org.eclipse.ui.navigator.navigatorContent.

Building a Common Navigator based viewer, Part III: Configuring Menus

2006-06-16T16:06:00.000-04:00

Action is eloquence.
-- VOLUMNIA
Coriolanus, Act 3, Scene 2

In earlier posts, we walked through how to construct a Common Navigator Framework (CNF) viewer and a basic extension to render property files. Now we will walk through how to configure the menu for a CNF viewer and how to add actions to our viewer to manipulate our content.

Let's take a small step back though, and look at the current roadmap for upcoming posts:

Configuring CNF viewer popup menus (Part III). This post will describe how to configure the popup menu of a CNF viewer, how to describe the insertion points and separators for a popup menu, and how to toggle whether a CNF viewer honors the org.eclipse.ui.popupMenus extension point.
Adding Actions to a CNF viewer through Object Contributions (Part IV). Part IV will cover how to add actions through Object Contributions. Object Contributions allow you to add actions (and even define menu sub-structures) for specific object types. Object Contributions are not specific to CNF viewers, but they are useful for adding menu actions without alot of code.
Adding Actions to a CNF viewer through Action Providers (Part V). Part V will cover how to programmatically configure CNF menus and adjust the retagetable actions for the Workbench. In particularly, the example will cover how to add a custom Open action for individual property types.

Overview

There are two basic options for adding actions to a Common Navigator Framework (CNF) viewer:

Contribute actions using org.eclipse.ui.popupMenus as objectContributions or viewerContributions. The ...popupMenus extension point allows you to contribute individual action delegates throughout the Eclipse Workbench. CNF viewers can be configured to honor these contributions (which is the default) or to ignore them. In the case of the Project Explorer contributed by Platform/UI, object and viewer contributions are honored. (To be covered in detail in Part IV.)
Contribute actions using org.eclipse.ui.navigator.navigatorContent as actionProviders. Sometimes, clients require more programmatic control over exactly what actions are contributed to a given menu in a particular context, as well as what retargetable actions are configured based on the current selection. CNF Action Providers are only honored by CNF viewers. (To be covered in detail in Part V.)

Configuring Menu Structure

In Part I, we defined our example <viewer /> element, and popup menus were briefly mentioned.

Recall that there are two means to configure a popup menu. The first possibility is simply to specify a value for the popupMenuId of the <viewer /> element in org.eclipse.ui.navigator.viewer. The second possibility is to take a more active role in configuring the insertion points the menu supports.

Tip: It is an error condition if both the popupMenuId is specified as well as the popupMenu element.

If we were to set the popupMenuId, we might have something like the following:

The identifier can be used by extenders of org.eclipse.ui.popupMenus to add viewerContributions specific to the view; however, no identifier is required for objectContributions.

When only the popupMenuId attribute is specified, the default set of insertion points are automatically configured in the popup menu. These are documented in the schema reference for org.eclipse.ui.navigator.viewer, but are duplicated here for convenience:

"group.new" separator="true"
"group.goto"
"group.open" separator="true"
"group.openWith"
"group.edit" separator="true"
"group.show" separator="true"
"group.reorganize"
"group.port" separator="true"
"group.generate" separator="true"
"group.search" separator="true"
"group.build" separator="true"
"additions" separator="true"
"group.properties" separator="true"

These values can be used by the menubarPath attribute of elements in org.eclipse.ui.popupMenus.

These values can also be used when programmatically using or searching for menu items (see org.eclipse.jface.action.IContributionManager, particularly insertAfter(), insertBefore(), and appendToGroup().

All of the string constants ("group.*") are immortalized in org.eclipse.ui.navigator.ICommonMenuConstants for programmatic usage.

Alternatively, we could choose to define a <popupMenu /> element as a child of <viewer />, where we could then define our own mix of insertion points. Remember, that you can use the Extensions tab of the Plug-in Manifest Editor to drive the creation of extension elements from the menu.

For our example, we can use the same menu configuration as the Project Explorer:

Each <insertionPoint /> element indicates a GroupMarker that is accessible through the IContributionMenu API. Where ever the separator attribute is set to true, the menu will render a horizontal line. The menus in Eclipse are smart enough to only render the line if necessary, so two lines back to back only renders as one horizontal line.

Also, take note of the allowsPlatformContributions="true" attribute of <popupMenu /> element. By default, CNF viewers are enabled to honor ..popupMenus contributions. Setting this attribute to false will restrict the menu to only honoring Action Providers.

The example above doesn't do anything fancy, but in your own CNF viewer, you could define your own menu insertion point ("group.example") where ever it makes sense for your scenarios. The recommended naming convention is "group.*", as the above insertion points follow, with the exception of the special additions group.

Some comments on extending or manipulating the set of insertion points on a CNF menu. It is not possible to declaratively manipulate or extend the set of insertion points for an already configured viewer. It is possible to programmatically add new GroupMarkers or Separators through Action Providers, but this practice should be used with care. We will get into the details of how this might be done in Part V, but for now just heed the warning that this practice should be used with caution, and only when taking advantage of the dependsOn attribute of the <actionProvider /> element, where the value indicates the identifier of an Action Provider that adds extra insertion points to the menu. Insertion points should never be programmatically removed as other extensions may depend on them. If your own custom viewer has no use for a particular insertion point, then you can leave it out when you define your own <popupMenu /> element.

Summary

In this article, we have discussed how to configure a menu for a Common Navigator Framework (CNF) viewer. In the next few articles, we will discuss how we can add to this menu using org.eclipse.ui.popupMenus and org.eclipse.ui.navigator.navigatorContent/actionProvider.

What does the Common Navigator Framework (CNF) help me do?

2006-06-05T07:47:00.000-04:00

A framework should help you do something, not make you do something. In the following article, I'll go over the scenarios that motivated the creation of a generic, viewer integration framework. I'll also discuss a little of the background of the framework and how it evolved to an open source solution for the Eclipse Platform.

The details of this article roughly follow the flow from the presentation given at EclipseCon 2006.

Use case 1: Expose various types of information in a viewer to provide a cohesive user experience with editors.

One of the greatest features of Eclipse is its inherent extensibility. However, in some cases, the way in which the extensibility of Eclipse is utilized can come at the cost of the user experience. One problem that many products have come across when extending Eclipse is viewer explosion, where many views for different tasks are created to satisfy the requirements of each individual component. Depending on the overall product architecture, the views may sometimes duplicate information (such as each view rendering the project and its resources, plus one other piece of value-added content for each project), or alternatively the views may render just their data, which means that if the user is exploiting function from multiple components within the product, s/he may have to keep multiple views open.

The pattern that many components teams follow tends to be a viewer that exposes a custom model (like a J2EE Deployment Descriptor, as in the Web Tools Platform) plus the resource or Java(tm) representation of the project.

It turns out that this pattern is really driven by integrators incorporating the editor model into their viewers. Often, the extra content in a viewer is really a representation of some model that an editor can operate on, which is exposed to the user to make it easier for them to manipulate or navigate. So the first requirement of fight club .. err the CNF is:

Requirement: Support a single viewer for all editor model integrators.

Use Case 2: Expose model elements that are not tied directly to the workspace.

Not all viewers follow the editor model pattern; some viewers follow the pattern of incorporating data from outside the workspace environment to make it easier for users to have a "one-stop" shop for all of their development needs. The database extensions in WTP are an example of this:

Now merging all of the content of these views in one place can overwhelm the user, so the CNF must allow users to choose what is relevant to them.

There are two requirements derived from this scenario:

Requirement: Allow non-resource driven model content.

Requirement: Allow users to choose what they want to see in their integrated viewer.

Use Case 3: Open Source Platform must allow integration from Commercial Products.

One of the biggest value propositions of Eclipse is for vendors to pool resources to produce the commodity layers; then vendors can differentiate themselves to provide value-added content based on their customers' needs. The Web Tools Platform is one of the first big examples where many different kinds of viewer content would be required for end-users, both from standard and proprietary models, and therefore vendors must not be restricted from extending the primary navigational viewer.

A similar problem exists on the level of commercial products, where value-added content from Independent Service Vendors (ISVs) must be able to integrate seamlessly to enhance the user experience. Often, the integration paths for ISVs are not as well documented as an open source platform, so providing a solution on the open source layer allows the ISVs to use the same consistent, public, documented API that the community has helped hone.

So the general use case here is to allow extensibility across layers of software; downstream layers must be able to integrate seamlessly to maintain a cohesive user experience.

Requirement: Allow Platforms (open source and commercial) to reuse a consistent viewer integration framework and API.

So in summary, there are four basic requirements of the CNF:

Support a single viewer for all editor model integrators.
Allow non-resource driven model content.
Allow users to choose what they want to see in their integrated viewer.
Allow Platforms (open source and commercial) to reuse a consistent viewer integration framework and API.

In addition to the requirements above, there were a few goals driven from experience with developing Eclipse viewers from release to release:

Enhanced reusability. Clients should be able to re-use Platform content (Resource model, Java(tm) model, etc) with little or no code; and clients should be able to define their own viewers an "absorb" content easily.
Mitigate client reaction from release to release. Eclipse continues to evolve at all levels as an effective Platform. Often enhancements are made at the lower levels (such as the enhanced working set support from JDT in 3.1). For downstream integrators to adopt this functionality, it often requires an expensive porting or coding effort, in addition to whatever value-added content is slated for that product's own release. The CNF should make it easier for clients to absorb these enhancements without coding efforts.

The CNF began as product solution in Rational(R) Application Developer (RAD) v6.0. It was originally derived from the General Purpose Navigator proposal for Eclipse 3.0. The GPN was a great start, but much of the original code has been re-written; however some of the concepts still remain.

When IBM Rational decided to contribute some of the lower integration layers of RAD v6.0 to the then newly formed Eclipse Web Tools Platform project, the CNF was included in the contribution. Product solutions often have very different focuses from Platform solutions, as the measure of value in a product solution is on the user experience, not on the ease of extendibility. Some initial API definition was done in the context of WTP, but there was uncertainty at the time about the proper home for the CNF. Like many of the frameworks in WTP, it is not specific to any particular specification, and solves a general problem required for products built on Eclipse. Therefore, it was expected that the proper home for the CNF was in the Platform. At the time, it wasn't clear that the Platform would be willing to accept the CNF or if another version or solution would present itself, so the effort invested to harden the CNF API in WTP was minimal.

In Eclipse 3.2, it was agreed that the Platform would adopt the CNF, with the proper API finalization that was required. I've had requests to provide some thoughts and feedback on what it takes to turn a product solution into a platform solution, and I hope to address that in a future post.

So in a nutshell, the CNF is designed to help you integrate document models into an navigator experience, integrate content that isn't specific to the workbench, allow you to absorb other content seamlessly (in particular resource and Java(tm) models), and mitigate your expense in time and effort to absorb incremental enhancements from release to release from layers beneath you. The CNF began as a product solution for a general problem in Rational Application Developer v6.0, and has been contributed to the open source Eclipse Platform in 3.2 to allow the community to better integrate their navigational viewers and provide a more cohesive user experience across software layers and products.

Where do we go from here?

2006-05-27T17:11:00.000-04:00

So far, I've posted two articles on how to get started with the Common Navigator Framework (CNF). There's alot more that can be done though, and I'd like feedback from you about what you're most interested in. Eventually, most if not all, of the pieces of the framework will have an article, but the prioritization should be driven by the community. To that end, I ask the wildly open end question, what do you want to learn about next?

There are several large posting topics that come to mind right off:

Use cases and motivation for an extensible viewer. The posts so far jumped right into building extensions, but some in the community may not see the reason for having an extensible viewer framework. Is this topic worth an article? Does anyone care about the history or the evolution of the CNF? Or the lessons learned along the way? Or what about what it takes to contribute a component to the Eclipse Platform -- turning a product solution into a Platform-worthy API?
Contributing or consuming actions. You can contribute actions or use the API in your own viewers to drive generically extensible menus. You can also structure action extensions that are turned on and off with their content extension, or you can structure menu contributions that have dependencies on other menu contributions (such as contributing to a submenu). The CNF supports object and viewer contributions as well as a CNF-specific programmatic menu builder. You can also contribute to the retargetable actions of the workbench based on the selection in the viewer. Which of these articles would be valuable to you?
Filters. I covered some of what you can do with filters in the first posting, was this enough? Do you want to see a programmatic example?
Sorting. Sorting in a generic viewer is a nontrivial problem because there does not seem to be an intuitive approach. Therefore, one has to be arbitrarily decided. Even then, some may disagree with the limitations that are imposed. Are any of you interested in providing feedback about what you'd expect? Or do you just want to see an example of contributing sorters to a CNF viewer?
Drag and Drop. The CNF supports extensibility for drag transfer data types (specific to the viewer) and extensiblity for drop handling (specific to extensions). You can contribute a DND handler for moving items within a viewer or for moving items from a Common Navigator to another an editor or view in the workbench. Would you like to see how to define your own transfer data type for a viewer? Or what about just adding your own drop handler?
Reusing the API outside of the org.eclipse.ui.navigator.CommonNavigator view-part implementation. There are many pieces of the CNF that are designed to be reusable outside of the standard view part implementation. Indeed, Michael Valenta's post is a great example of using the API to construct your own custom extensible viewer class, which doesn't depend on org.eclipse.ui.navigator.CommonNavigator or CommonViewer.

Then there are several smaller topics that might be of interest:

Defining retargetable actions. The CNF allows extensions to define their own default Open action (e.g., what happens when the user double clicks a node you've added?), as well as all of the other retargetable actions defined by the workbench (see org.eclipse.ui.actions.IActionFactory) or your own custom retargetable actions.
Setting text in the status bar of the workbench. CNF extensions may use different text to describe their items in the status bar of the workbench than they use to label the item in the viewer.
Using custom fonts and color for items. Who says that plain old font is good enough? Get fancy with it.
Using mementos to restore or persist state between sessions. CNF extensions may remember state from session to session, providing consistency in the user's experience.
Binding an extension programatically to a viewer. You've seen how to bind an extension to a viewer using the org.eclipse.ui.navigator.viewer extension point, but did you know you can drive this directly through the API?
Turning extensions on and off programatically. Again, the CNF allows you to programmatically customize a viewer using the API.
Defining and Using Wizard Shortcut actions. The CNF allows extensions to declare wizard shortcut actions based on existing org.eclipse.ui.xxxWizards extensions. The text and icon is automatically picked up from the wizard definition, which means the action's text and icon updates when the wizard definition changes. Consumers of the framework can also reuse the API in their own viewers, without any CNF dependencies to render their own context menu with New, Import, and Export wizard shortcut actions with very little code.
Hiding the default toolbar buttons and tabs in the filters dialog. Some viewers don't care about link with editor or collapse all, and some viewers don't want to expose the ability to turn filters or extensions on and off to the user. Care to know how?
Adding a link with editor handler. An oddly placed addition to the CNF is the link with editor extension point. It's not really core to something like the CNF, but it's something that most viewers (particularly navigational viewers) need. For custom editors or models, clients can add their own link with editor handlers; would this be interesting to you?

I'll end this posting with a couple of diagrams I used at EclipseCon 2006 to convey a high level conceptual model of how the extension points are structured. Feel free to post your own questions about these diagrams or your own topic ideas.

In each diagram, the boxes with the component icon (the not-green-C, not-purple-I icon) are the elements in the extension point. The other boxes (with green Cs and purple-Is) show the classes or interfaces (respectively) defined by the element. The allowed cardinality is denoted between each element and its child.

The first diagram shows the org.eclipse.ui.navigator.navigatorContent extension point.

The second diagram shows the org.eclipse.ui.navigator.viewer extension point.

Building a Common Navigator based viewer, Part II: Adding Content

2006-05-22T17:38:00.000-04:00

In this post, we're going to walk through adding a simple content extension to the viewer we defined in the last example. To avoid getting bogged down in an overly complex content provider and label provider, we will focus on a file structure with a very simple model, in this case a plain old *.properties file. When finished, our content extension will allow us to expand any *.properties file in the Example viewer and render the data in the file right in the viewer.

You may also download the full example as it stands at the end of this posting.

First, let's take a look at what the content extension will look like in the plugin.xml file. If you have read the last post, you'll know that you can build an extension like the following example using the Extensions tab of the Plug-in Manifest Editor. First by selecting Add... on the Extensions page, choosing org.eclipse.ui.navigator.navigatorContent, then using the right-click menu, and following the New > navigatorContent menu path. Alternatively, you can create this extension in the plugin.xml tab of the same editor. Either approach is fine, but the first approach drives the New menu from the Extension Point Schema, so you will see other options that are available in the raw plugin.xml tab.

The extension declares a content extension with the id "org.eclipse.ui.examples.navigator.propertiesContent" with the display name "Properties File Contents". The name is the string used in the "Available Extensions" tab of the Filters dialog.* We will get into the code for the content and label providers shortly, but for now just note that each are specified; you cannot specify just one or the other.

Finally we set some attributes to tell the framework how we would like our extension rendered in the viewer.

activeByDefault determines whether the extension should be active in the default configuration (e.g. new workspace).

icon determines what icon should be used when referring to the extension in the User Interface

priority is used in a couple of different ways. The most prominent is to determine the relative ordering of items in the viewer (highest priority items towards the top of the viewer down to lowest priority items towards the bottom of the viewer). In general, either "normal" or "high" should be sufficient for most extensions, indicating that they should be mixed in with the resources extension (when priorities match, the label is used to sort items alphabetically) or placed just above resources under projects.

Within each <navigatorContent /> element, we can specify many different types of extensions, but before we grow the example, we must describe to the framework when our extension should be invoked. We need to describe when we can provide children, parents, or labels and icons for nodes in the tree. We do this using Eclipse Core Expressions. For now, I'll refer you to the documentation for org.eclipse.core.expressions for more detail on what is possible with these, or you can use the New > ... menu in the Extensions tab to create these easily.

For content extensions, there are two important expressions: <triggerPoints /> and <possibleChildren />.

The <triggerPoints /> expression indiciates which types of nodes in the tree might be interesting to our extension. When the framework finds a node that matches the <triggerPoints /gt; expression, our extension will be invoked to provide elements or children for that node. Our extension may not be the only one to be given the opportunity to provide children, as the framework will aggregate all contributed children under each node.

The <possibleChildren /> expression indiciates which types of nodes in the tree our extension may be able to provide a label or parent for. For your scenarios that must support link with editor, or setSelection() on the viewer, the <possibleChildren /> expression must be accurate and complete.

Once we have an extension defined, we must bind it to the viewers we want it associated with. Specifying a <viewerContentBinding /> indicates that any extension which matches an included pattern is visible to any viewer with the viewerId specified in the <viewerContentBinding /> element. Recall that we saw these in the last posting.

For the example, we will bind our properties content extension (with id "org.eclipse.ui.examples.navigator.propertiesContent" to our Example View (with id "org.eclipse.ui.examples.navigator.view").

Now that we have setup our extension, let's take a look at the code that will actually do the heavy lifting.

First, we need a model. A properties file has an extremely simple structure, and we will model this using just one type of model object, called PropertiesTreeData, which will have three fields: name (the name of the property), value (the value of the property), and container (the file that contains the properties model. One of these model elements will be populated for each property in the *.properties file.

In our example, the properties model will only be loaded when requested through the content provider. The content provider is used by the framework to determine the children of each element in the tree, or for any given element, determine its parent (or parents as there could be potentially more than one).

Our example content provider implements org.eclipse.jface.viewers.ITreeContentProvider to provide information about the tree structure. The Common Navigator framework also supports implementations of the new org.eclipse.jface.viewers.ITreePathContentProvider, but that is out of scope for this example.

The PropertiesContentProvider also handles some of the other functions required by our extension, such as listening for resource changes and updating the model (and viewer) accordingly. We will not go over these in this posting, but you can see how it works in the full source.

For now, we will focus on the viewer integration methods as defined by ITreeContentProvider.

An ITreeContentProvider must implement getElements(Object input), getChildren(Object parent), hasChildren(Object element) and getParent(Object element).

The getElements() method is queried for elements at the root of the viewer. Many implementations will just forward this call to getChildren(), and that's just what we'll do.

The getChildren() accepts an object (in our case either a *.properties IFile or an instance of our PropertiesTreeData model object because we described these in our <triggerPoints /> expression.

In the following implementation, we check to see if the incoming element is an instance of org.eclipse.core.resources.IFile and if the file extension ends in *.properties. If the incoming element meets these criteria, we check our cache of loaded models or attempt to load the model if not cached. The method updateModel() will create a PropertiesTreeData object for each property, and cache what it finds in the cachedModelMap. Check out the full source to see how updateModel() is implemented.

The hasChildren() method is optimized to return true whenever it is called with an IFile with the *.properties extension. The other alternative is to eagerly load the contents of the file to perform the calculation, but that approach comes with an added performance penality.

If called with a PropertiesTreeData model element, hasChildren() will return false, since none of our model elements may have children (a property has no children, but other models clearly may).

The getParent() method will return the IFile that contains the PropertiesTreeData item or null if called with any other object. The Common Navigator framework will continue querying other extensions until a non-null parent is found or all relevant extensions have been queried. Recall that an extension may be asked to provide a parent for an element if that element matches its <possibleChildren /> expression.

Finally, the label provider of our content extension tells the viewer how to render the icon and label for our model elements (PropertiesTreeData). Since we're only conerned with these elements, we do not need to worry about providing labels or icons for any other elements. Other extensions will render the labels and icons for other elements in the tree.

The PropertiesLabelProvider implements org.eclipse.jface.viewers.ILabelProvider and also org.eclipse.ui.navigator.IDescriptionProvider.

ILabelProvider is the default interface required for proving labels and icons by JFace.

IDescriptionProvider is specific to the Common Navigator framework and is used to provide text for the status bar in the lower left hand corner of the Eclipse window.

The methods required by ILabelProvider are getText() and getImage(). We will render the label for our model elements as the "name= value" string for the property (without the quotes). For the icon, we just use one of the shared icons provided by Platform/UI.

The label provider will be queried for labels, icons, or descriptions for any element contributed directly by the extension or for any element that matches the <possibleChildren /> expression for that extension. If null is returned for the icon or the label, the framework will continuing other applicable extensions based on their <possibleChildren /> expressions and viewer bindings. If your extensions wishes to pass on its opportunity to provide a label or icon, always return null.

And that's it. The final view renders properties files right in our Example View.

*-In general, you should externalize your strings, but we will not worry about that for these examples.

Building a Common Navigator based viewer, Part I: Defining the Viewer

2006-05-20T14:41:00.000-04:00

I've started fielding questions about the Common Navigator on the eclipse.platform newsgroup and the message from the community is resoundingly that there are not enough examples. In order to help the community adopt the Common Navigator framework, I'm going to be fleshing out some examples (in the Eclipse repo at dev.eclipse.org:/home/eclipse, where you can login as "anonymous"; see the wiki for more information. I will be documenting these examples here in this blog. Eventually I will intgrate the documentation that evolves here back into the Platform SDK, but I want a forum where potential consumers can provide feedback easily and directly to the distribution media (e.g. this blog).

Specific documentation on the extension points and API is available in the Eclipse Platform Help (Help > Help Content) under the Platform Plug-in Developer's Guide > Reference > API Reference | Extension Points Reference. The relevant extension points are org.eclipse.ui.navigator.viewer and org.eclipse.ui.navigator.navigatorContent. The relevant API packages are org.eclipse.ui.navigator. If you'd like more details on the specifics mentioned in this post, please follow up with these references.

So where to begin? First we're going to configure our plugin that will contain the viewer to add org.eclipse.ui.navigator to its dependencies. Then we're going to define a view part using the org.eclipse.ui.views extension point and specify the org.eclipse.ui.navigator.CommonNavigator class as our view part implementation, which will provide a cradle for our viewer. Then we will define a org.eclipse.ui.navigator.viewer extension to configure the viewer as a Common Navigator. Finally, we can define org.eclipse.ui.navigator.navigatorContent extensions along with bindings (org.eclipse.ui.navigator.viewer/viewerContentBinding) to associate extensions with our viewer.

You don't have to use org.eclipse.ui.navigator.CommonNavigator in order to take advantage of the framework; you could embed content using the org.eclipse.ui.navigator.INavigatorContentService virtually anywhere from dialogs to editors or define your own viewer and view part class, but for this example, we're going to stick to the basics.

Basic Setup

The Common Navigator Framework is a feature that is new to Eclipse 3.2. Therefore, you must have an update to Eclipse 3.2 environment installed. The topic of this post will not get into setting up Eclipse for self-hosting development. I assume that you have Eclipse 3.2 setup and are either self-hosting against a target of your own choice or the default.

Before we do anything, we need to make sure that we have our plugin configured with the necessary dependencies. Either create a new Plugin (File> New> Project: Plug-in Development> Plug-in Project: Set the name and accept the defaults), or open up the Plug-in Manfiest Editor (select the "plugin.xml" file in your viewer of choice (Project Explorer, Package Explorer, Navigator, etc) and double-click or right-click and select Open With> Plug-in Manifest Editor. On the Dependencies tab, click Add... and begin typing org.eclipse.ui.navigator and select it when it is highlighted or when you see it in the list.

Now select the Extensions tab of the editor.

Defining the view part

When defining a Common Navigator enabled viewer, you must declare the actual view part. Eclipse view parts are defined by the org.eclipse.ui.views extension point. A view part is the container for our viewer; it has a tab handle with a label, a place for a view menu (the little triangle in the top right corner of the view part), and can contain any widget that we need to display to the end user. View parts are not specific to Common Navigators, we just need a cradle to hold our viewer.

You can define the view through the Extensions tab by selecting Add... and begin typing org.eclipse.ui.views until you see it in the list. Then right-click on the entry that is created under the "All Extensions" tree named org.eclipse.ui.views and choose New > view. This will create the element in the plugin.xml file.

When you select the view element, the available attributes for the element should appear as editable textboxes and widgets on the right. We are going to enter the following values (without the quotes):

id: "org.eclipse.ui.examples.navigator.view"
name: "Example View"
class: "org.eclipse.ui.navigator.CommonNavigator"
icon: "icons/filenav_nav.gif" (or your own)
allowMultiple: false

Now select the "plugin.xml" tab of the editor. You should see something like the following. You can choose to create a category as in the diagram, but be sure to indicate which category your viewer should be associated with by specifying the "category" attribute of the viewer. Otherwise, your viewer will appear in the Other category of the Show View dialog (Window > Show View > Other...).

Defining the viewer configuration

Once we define the view part, we need to define a configuration extension for our view part (org.eclipse.ui.navigator.viewer) which will tell the framework some basic things like which view part is a Common Navigator, what the structure of the popup menu should be, and whether to respect object contributions, in addition to properties that influence the default behavior of the viewer.

Open the Extensions tab again on the editor and click Add...; when the dialog appears begin typing org.eclipse.ui.navigator.viewer until you see it in the list and then select it. Right-click on the new org.eclipse.ui.navigator.viewer element in the "All Extensions" tree and choose New > viewer. The element will allow us to associate an abstract Common Navigator viewer with a specific view part. The abstract viewer is what extensions are associated with, regardless of whether the viewer is embedded in a view part or elsewhere. So for this example, we'll use the id we used above in our org.eclipse.ui.views extension ("org.eclipse.ui.examples.navigator.view"). Select the element in the view (which will be labeled name-of-your-plugin.viewer by default) and change the viewerId in the text box that appears on the right to "org.eclipse.ui.examples.navigator.view" without the quotes.

Some comments on popup menus. The Common Navigator framework has two means to allow viewers to customize their menus. The first way to configure the popup menu is to specify the popupMenuId of viewer to accept the default separators and group marker ids for the menu. The default values are documented under the org.eclipse.ui.navigator.viewer extension point, but are reproduced below for convenience. Alternatively, you could choose not to specify a popupMenuId and instead specify a <popupmenu /> element as a child of the <viewer /> element. Here, you may define your own separator and group markers for your downstream clients to add to. If you expect to bind the content or actions of the content extensions provided by the Platform (Resource, Java(tm)), then it is recommended that you use the default groupings.

"group.new" separator="true"
"group.goto"
"group.open" separator="true"
"group.openWith"
"group.edit" separator="true"
"group.show" separator="true"
"group.reorganize"
"group.port"
"group.generate" separator="true"
"group.search" separator="true"
"group.build" separator="true"
"additions" separator="true"
"group.properties" separator="true"

Some comments on options. The < options /> element under the <viewer /> element allows you to specify String-based name=value pairs. There are a few options used by the base framework (documented in the Examples section of org.eclipse.ui.navigator.viewer), but the mechanism can be used by your own viewers or extensions to provide extra configuration to extensions bound to the viewer. See org.eclipse.ui.navigator.INavigatorViewerDescriptor for the API to read the properties specified in a <viewer />element. You can get to the viewer descriptor via the org.eclipse.ui.navigator.INavigatorContentService of a Common Navigator viewer.

Once you have set the viewerId, you can select the "plugin.xml" tab to see the following element defined.

After defining the viewer, we will need to add content extensions and bind them to the viewer. I'll cover this in more detail in the next post. For the example we'll simply bind the default resource content (defined by the org.eclipse.ui.navigator.resources plugin) to our viewer.

Go back to the Extensions tab, right-click on the org.eclipse.ui.navigator.viewer extension and choose New > viewerContentBinding. Select the viewerContentBinding element and set the viewerId to the id we are using for our example viewer ("org.eclipse.ui.navigator.examples.view").
Right-click on the new viewerContentBinding element, and choose New > includes. Finally, right-click on the new includes element
and choose New > contentExtension. For the pattern attribute of the contentExtension we will specify "org.eclipse.ui.navigator.resourceContent" without the quotes, which is the identifier used by the org.eclipse.ui.navigator.resources plugin to identify the Resource extension.

On the "plugin.xml" tab, we should have something like the following:

You may now launch the workbench (Run... > New Eclipse Application) to see the viewer in action. We haven't bound any actions to it yet, so you'll need to use either the Resource Navigator or the Package Explorer to create projects that you can see in the viewer. We'll add Resource actions and filters next, but for now, take notice of the default behavior associated with the viewer. The Collapse All button, the Link with Editor button, the Filters button (along with a Filters ("Available Filters") tab and an Extensions ("Available Content") tab.

To bind the resource filters, we need to add another contentExtension element to our includes. Specify "org.eclipse.ui.navigator.resources.filters.*" as the identifier. This will pick up all resource filters defined by org.eclipse.ui.navigator.resources. Alternatively, you could select the individual filters you want by look at the plugin.xml file of that plugin and picking out the identifiers.

Select Run... again and verify that you now have several resource filters in your "Available Filters" tab of the Filters dialog.

Next we'll bind the default resource actions. To bind actions, we need to add a viewerActionBinding to the root of our extension point. Right-clikck org.eclipse.ui.navigator.viewer and select New > viewerActionBinding. Make sure the viewerId is the correct, and then add an includes element that has a actionExtension element. For the pattern attribute, specify "org.eclipse.ui.navigator.resources.*". Now when you Run... the workbench, you'll see New, Import, Export, and Refresh by default in the empty viewer, and other actions approximating the Resource Navigator when you select elements in the viewer.

Your plugin.xml at this point should look like:

"How does he know all the right ids? This is a little too "magic number for me!" To locate the identifiers of content extensions you would like to bind to your viewer, you can peruse the plugin.xml files of plugins that define the extensions. You can use the Plug-ins view to make this easier (Window > Show View > Other...: PDE > Plug-ins) or you can open the plugin.xml file of org.eclipse.ui.navigator.navigatorContent (using the Plug-ins view, even) and on the Extension Points tab, select navigatorContent. Then click Find References to locate all extensions in your workspace that define content or action extensions you might want to use in your own viewer. Content extensions are defined by the navigatorContent element, so use the id attribute of navigatorContent extensions you would like to bind when you define contentExtension elements under viewerContentBindings for your viewer. Action extensions are defined by the actionProvider element, so use the id attribute of the actionProvider extensions you would lik to bind when you define actionExtension elements under viewerActionBindings for your viewer. Keep in mind that actionProvider that are nested under navigatorContent extensions are automatically bound when their enclosing content extension is bound to a viewer.

Defining Filters

The last thing we are going to do today is define a filter for our viewer using Eclipse Core Expressions. Documentation on the Core Expressions framework is available with the org.eclipse.core.expressions plugin. We are going to use the property testers defined by org.eclipse.core.resources to test for a specific project nature, and hide all projects which do not have this project nature.

So back on the Extensions tab of the Plug-in Manifest Editor, select Add... and choose org.eclipse.ui.navigator.navigatorContent. Then add a new commonFilter element to this extension (same as before: right-click on the org.eclipse.ui.navigator.navigatorContent element, choose New > commonFilter). Change the suggested id to "org.eclipse.ui.examples.navigator.filters.hideNonJavaProjects", and change the name to "Hide non-Java projects". Instead of specifying a class implementation, we are just going to define the expression in terms of XML. Right-click on the commonFilter element and select New > filterExpression. From here, we can continue using the right click menu to create an expression like the following:

You can also set the activeByDefault attribute in the extension to determine whether the filter is active in the default configuration.

Finally, we need to define a contentExtension as part of our viewerContentBinding for this viewer. Be sure to use the id of our new filter, or a generic pattern (like "org.eclipse.ui.examples.navigator.filters.*") to bind this filter and all future filters that we (or our downstream contributions) define that match this id. Your final plugin.xml should look like the following:

Now Run... the workbench one last time. Create a few Simple projects and a few Java Projects. When the "Hide non-Java Projects" filter is enabled, the Simple projects should disappear from the view.

Why would scribbledideas be interesting to read?

2006-05-20T13:11:00.000-04:00

I started scribbledideas to better engage in the global discussion that is the internet. I hope to use this forum to post thoughts and information on some of my professional activities, solicit feedback from consumers of technology I have a hand in at my day job, and perhaps throw out an occasional review of a good cigar or perhaps even a good scotch.

For the most part these days, my development efforts focus on Eclipse or Eclipse-based commercial products produced by IBM. In the open source arena, my most recent contribution is the Common Navigator Framework, but before that I had a hand in many of the visceral frameworks in the Eclipse Web Tools Platform (WTP) relating to project structuring, EMF model management, and J2EE tooling. Currently, I am one of several IBM committers to the new Eclipse Services Oriented Architecture (SOA) Tools Platform.

I've been a Java developer for about seven years in various domains from assembly line management software, to enterprise Business to Business communcations, to Eclipse-based desktop software. My interests these days are in the design of solid, robust Application Programming Interfaces (API) and encapsulated, evolveable frameworks.

As an undergrad, I participated in several student research competitions, including taking First Place in the ACM/SIGCSE International Student Research Competition, twice (2001 and 2003); and First (2001) and Third (2003) respectively in the ACM Grand Finals International Student Research competitions. I was fortunate to be able to particpate in these activities as part of the research group run by my undergrad advisor, Hayden S. Porter, of Furman University, where I received a B.S. in Computer Science in 2003. Currently, I am pursuing an M.S. in Computer Science part time from the University of North Carolina at Chapel Hill.

My outside interests (as I alluded to before) center around watching boxing, fine bourbon or scotch, and cigars. I also like grilling meat over fire and cooking. Of course, these activities are always enhanced with good music or if carried out at fine restaurants, jazz clubs or cigar cafes.