Step 3: Implementing the View
To implement a view we need a class that extends ViewPart. Based on what I defined earlier, the name of the class should be RegExView in the expressionViews package. Additionally, because ViewPart is abstract and implements IViewPart, RegExView must implement the createPartControl() and setFocus(). The initial implementation of RegExView is as follows.

package expressionViews;import org.eclipse.swt.widgets.Composite;import org.eclipse.ui.part.ViewPart;public class RegExView extends ViewPart {		public void createPartControl(Composite parent) {			}		public void setFocus() {		//ignored	}}

The first method, createPartControl(), is called when Eclipse first creates the view. This is the method where the UI for the view will be implemented. The second method, setFocus(), is called when the view receives focus. Due to the nature of the views defined in this article there is no need to perform any operations when focus is set.

For the RegEx view, the UI will contain several widgets. First, you need a text box for the expression itself. Second, you need a text box containing the text to evaluate the expression against as well as a label that displays results to users. Finally, you need labels for both text boxes and a button to execute the RegEx.

Building UIs using SWT is a large subject that I won’t cover in this article. For an introduction to this subject, see “SWT Creates Fast, Native-looking GUIs for Your Java Apps,” by Raghu Donepudi or “Understanding Layouts in SWT” by Carolyn MacLeod.

The first step for building the UI is to create a layout that will organize the widgets. I have decided to use GridLayout in this case. As such, the first two lines of createPartControl() are as follows.

GridLayout gridLayout = new GridLayout();parent.setLayout(gridLayout); 

The method createPartControl() accepts as a parameter as a reference to its parent composite. As such, we want to apply our layout to the parent composite since it will contain our widgets. The next step is to create the expression text box:

GridData expGridData = new GridData();expGridData.horizontalAlignment = GridData.FILL;expGridData.grabExcessHorizontalSpace = true;Label expLabel = new Label(parent, SWT.NONE);expLabel.setText("Expression");exp = new Text(parent, SWT.BORDER);exp.setLayoutData(expGridData); 

The code for the expression text box, above, does three different things. First, a GridData object is created, which specifies the proper layout of a widget in a cell of the GridLayout. Next, a label widget is created and given a string of “Expression” to identify the expression text box. Finally, a text widget is created and the GridData applied to it. You’ll notice that the text is not declared here. I have chosen to make the expression text widget a private field of the class, so it can be easily referenced by other methods.
With that done, the next step is to create the text widget for the search text. This step is largely the same as the last step, but I have included it below:

GridData searchGridData = new GridData();searchGridData.horizontalAlignment = GridData.FILL;searchGridData.verticalAlignment = GridData.FILL;searchGridData.grabExcessHorizontalSpace = true;searchGridData.grabExcessVerticalSpace = true;Label searchLabel = new Label(parent, SWT.NONE);searchLabel.setText("Search Text");search = new Text(parent, SWT.BORDER);search.setLayoutData(searchGridData); 

Just like the expression text widget, the search text widget is also a private field of the class, thus ensuring it can be accessed by other methods. Next, the result label and evaluate button are created.

result = new Label(parent, SWT.NONE);Button eval = new Button(parent, SWT.BORDER);eval.setText("Evaluate");eval.addSelectionListener(this); 

You’ll notice that result is also not declared. This is because I made it a private field, for the same reason as with the expression and search widgets. Notably, the evaluate button has a selection listener added, which is done so that the class receives a SelectionEvent when the button is clicked. This also means that the class must implement the SelectionListener interface. Finally, the parent composite should be packed, so that all the widgets are drawn correctly, which is done by calling the pack() method on parent.

The final step is to add a widgetSelected method to the class, which is required by the SelectionListener interface. This method is included below.

public void widgetSelected(SelectionEvent e) {	String text = search.getText();	Pattern pattern = Pattern.compile(exp.getText());	Matcher matcher = pattern.matcher(text);		matcher.find();	result.setText(text.substring(matcher.start(), matcher.end()));	result.pack();}

The above method is called whenever the Evaluate button is pressed. To make it work, I compile the RegEx into a Pattern and then get a Matcher for it against the search text. Next, I get the first match and put the result into the result label and pack it so that it is redrawn.

Figure 4. RegEx View: Here’s a look at the newly created RegEx view.

With that the first view is complete and the plugin can be tested. There are several ways to test Eclipse plugins, but I recommend using the Runtime-Workbench. It allows you to run another instance of Eclipse inside of Eclipse complete with step debugging if you so desire (for more information see “Running a Plugin“).

Once you have Eclipse running with the newly created plugin you should be able to use the Window menu to open the view you’ve just created (see Figure 4).

Once the view is open you are free to create a RegEx and evaluate it against the search text. The results may not be impressive, but they are certainly useful. From here there are lots of possible enhancements one could make to the view. For example, it would be nice to have the search text matches be highlighted in the search text. It would also be nice if multiple matches found were displayed instead of just the first match.

The XPath View
With the RegEx view complete, I can now move on to the XPath view. The UI for the XPath view is exactly the same as the RegEx view, so really the only thing that needs to change is the widgetSelected() method. As such, the proper thing to do would be to create an abstract base class that both the RegEx and XPath views would extend. Whether you decide to do that or simply copy the RegEx view, the new widgetSelected() method for the XPath view is below:

public void widgetSelected(SelectionEvent e) {	try {	DocumentBuilderFactory fact = DocumentBuilderFactory.newInstance();	DocumentBuilder parser = fact.newDocumentBuilder();	Document doc = parser.parse(new StringBufferInputStream(search.getText()));	doc.normalize();		XObject obj = XPathAPI.eval(doc, exp.getText());	if(obj.getType() == XObject.CLASS_NODESET) {		NodeList nodes = obj.nodelist();		StringBuffer buf = new StringBuffer();		for(int itr = 0; itr < nodes.getLength(); itr++)			buf.append("[").append(nodes.item(itr).toString()).append("]");				result.setText("Result:  " + buf.toString());	}	else		result.setText("Result:  " + obj.str());	result.pack();	}	catch(Exception ex) {		ex.printStackTrace();	}}

As you can see from the code, evaluating an XPath is a little more complicated. First, the XML contained in the search text widget must be parsed into a Document instance. With that done, the eval() method of XPathAPI is called with the parsed Document and the expression contained in the expression text widget. The result of this can vary depending on the XPath. The code above looks for two types of results. If the result is a NodeSet then I loop over the nodes and place them inside brackets. Otherwise, the assumption is that the result can be handled as a string.

Before being able to test the newly created XPath view, you will need to declare it in the plugin manifest file. Below is the XML snippet I used:

"expressionViews.XPathView"     category="article.views"     name="XPath View"     id="article.views.xpath"/>