Archive

[I am deep into solving a CNF issue, but since I haven’t solved it yet you will have to settle for a bug fix.]

Random bug: when the cursor hovers over the custom navigator title bar a tooltip opens letting us know that the navigator can’t find a label for the root node. The full error message is Error: no label provider for R/. Tells you everything you need to know. Except what the problem is. Or how to fix it. Or, for Eclipse novices, what R/ means.

Luckily this is something that we are not afflicted with here at Hidden Clause. The message did tell us everything we needed to know. The Custom Navigator label provider is ignoring the root node used by the navigator (the R/ referred to in the error) and returning an empty string. The code for LabelProvider.getText() is:

(Notice how it so brilliantly ignores everything except elements of type ICustomProjectElement.)

What the message also tells us, by not telling us, is that our zero-length string appears to be causing consternation in the navigator. It is causing so much consternation that the navigator thinks no label provider is available to supply it with a default label for the root node.

That something is easily fixed in the LabelProvider. I’m not sure why Eclipse does not default to no string for the root (damn, those double negatives!), but it does not so we have to assign something to it. Since the standard behavior for other navigator views is to use the name of the view, in this case Custom Plug-in Navigator, that is what we will do.

For Those of You Who Care

I discovered the solution to the above by putting a breakpoint in LabelProvider.getText() and walking the call tree. NavigatorContentServiceLabelProvider.findStyledText() quite explicitly changed the original empty string returned by LabelProvider.getText() into a null which caused NavigatorContentServiceLabelProvider.getStyledText() to assign the error message to the navigator view. It makes sense, it just wasn’t what I wanted.

Extra credit: Run the Externalize String Wizard on LabelProvider.java and add the new string to the message.properties file.

While I firmly believe in test-driven development I do not believe in test-driven learning; that means that while tests are great to insure that your software works as advertised (or at least as much of it as you could think of), testing is not a good way to learn implementation. I know the physicists out there will disagree with me, but learning the black box behavior of a system is quite different than learning how to build the actual clockwork mechanism that makes something go.

With that said, at some point we do need to refactor the code and we can’t safely refactor the code without some tests to prove that our refactoring hasn’t broken anything.

We have been coding without a net in the interest of keeping the learning as noise-free as possible. Now we return to the part of the coding that we would normally do as we developed the code.

Open the customnavigator.test Properties dialog. In the Project References element put a check mark next to the customnavigator project. Click Finish.

Implement customnavigator.navigator.ContentProviderTest in the customnavigator.test project

Create a new JUnit class named customnavigator.navigator.ContentProviderTest

Test getParent()

Test getChildren()

Test hasChildren()

One of the tests, getChildren(), pointed out a bug: when a project came in, custom or not, it was being wrapped and saved in the _wrapperCache. The only projects that should be in the wrapper cache are projects of type CustomProjectParents. While not fatal, it was still wrong. Not a bad catch.

Why did we do that?

Just as a review about TDD from my rather narrow/myopic perspective (and not necessarily in this order):

Don’t test the platform

Don’t test trivial logic (i.e. trivial getters and setters)

Test boundary conditions that will cause errors

Test success conditions

So, what kinds of tests do we need? Well, the easiest way is to pretend we know how to implement the behavior, but haven’t actually written it yet. That should give us a clarity of purpose known only to those who already know the answer.

What does Eclipse expect the content provider to provide? Well, content. In our case, the content is the custom project in its variations; no other project/content types need apply.

As ContentProvider is just another POJO we can test it in a pretty standalone way. Also, even though our content provider implements an interface that extends an interface that extends an interface, we really only care about the methods we overrode. Of course, when I made the following list to see which methods I care about it turns out I had to override them all:

The EasyMock framework will also make these tests a simpler to implement. I am not going to try to convince you one way or another to use EasyMock or any other mock object framework. Every time I use EasyMock my life is easier. If there is a simpler mock object framework let me know, otherwise pick one and get to work.

For example, when I thought about the tests for ContentProvider I wasn’t sure which I should write first so I took the path of least resistence:

getParent()

Input: IWorkspaceRoot, Output: null

Input: IProject, Output: non-null

Input: ICustomProjectElement, Output: non-null (could be an IWorkspaceRoot, or one of the CustomProject wrappers)

Input: anything else (including null), Output: zero length array

getChildren()

Input: IWorkspaceRoot, Output: null if no projects exist or if the projects are not of of the Custom Project nature.

Input: IProject, Output: null (by defintion, if it were a CustomProject it would be wrapped already)

Input: ICustomProjectElement, Output: non-null unless if is a leaf child like CustomProjectSchemaFilters

Input: anything else (including null), Output: zero length array

hasChildren()

Input: IWorkspaceRoot, Output: false if the projects no proejcts exist or are not Custom Projects otherwise true

Input: ICustomProjectElement, Output: false if it is a leaf child like CustomProjectSchemaFilters, true otherwise

Input: anything else (including null), Output: false

Seems like a lot to think about doesn’t it? That is the whole idea. [Programming is no more about typing than writing is; in fact, programming is just as much about thinking as writing is.] Under what conditions can something fail? When it “succeeds” did it succeed properly? Some of the above I normally consider as I write the tests and others happen as I learn about the behavior as I implement. White boards are my friend.

Also, tests, like the ones for ICustomProjectElement, normally help you discover that you need data types like ICustomProjectElement. In this case, we skipped a few steps.

It’s okay; I forgive us.

Finally, I am not testing:

getElement(): since this calls getChildren() there is no reason to test this.

dispose(): I have no idea how I would do that. Sadly, I do have to make sure that I release any resources for which I am responsible, but I am not sure how I would do that except to simply remember that I need to do that in dispose() (can you say time bomb?). Also, it is trivial enough so I can safely ignore it for now.

inputChanged(): having implemented it I can safely say that testing an assignment at this point is…pointless.

resourceChanged(): This is purely GUI behavior. I suppose I could test it if the logic were complex, but for now it is not.

Being less than a TDD purist is hard to admit, but what the heck, I am not as much of a TDD purist as I would like folks to believe. Sometimes, I can’t come up with that perfect scenario that will light the way for me to create a host of absolutely incredible tests that will leave my code both bug-free and completely covered.

In any case, I am not going to go over every test or how I agonized over them or how much I drank to get through them. Red Bull is overrated.

More True Confessions

And this is where we write all kinds of test code for the CustomNavigator; only CustomProjects should appear and their various nodes should stay open if they were open when we changed something or should stay closed when we changed something.

We could test things like:

a generic project – assert an empty custom navigator in a fresh workspace

a custom project – assert one project in the custom navigator

a generic project and a custom project – assert one project in the custom navigator

There is only one problem (or perhaps we should consider it an opportunity): that is testing the platform. Making sure that ContentProvider is called with an IWorkspaceRoot was a plugin.xml configuration, not code, so what are we testing anyway? Actually, we would be testing the ContentProvider! Again!

I know we had fun doing it the first time, but I’ll pass on doing it more than once.

I am also not going to write any tests for CustomProjectParent or any of the children that come from it. Why? They are simple. No point wasting time on them until the logic contained by them is complex enough to warrant it.

Kinda makes you wish we had refactored them earlier. No worries; we do that in the next post.

What Just Happened?

Some of you may look at the tests and wonder how does using EasyMock make the job any easier? It is not about EasyMock; it is about testing the expected behavior from the code regardless of what the actual input is.

For example, in testGetChildrenForICustomProjectElementWithNoChildren() and testGetChildrenForICustomProjectElementWithChildren() I tested for an ICustomProjectElement with children and with no children, but I did it without using the CustomProjectParent type or any of its children. The reason for that is both simple and important: I am not testing CustomProjectParent or its children; I am testing ContentProvider. By mixing the testing of ContentProvider and CustomProjectParent (or any of the children) I run the risk of testing something I don’t need to test, or worse, forgetting to test something I should have tested.

Next time: Now that the tests are mostly out of the way it is time to refactor the children.

Why did we do it?

So, as we saw in a previous post, we can display a custom project that has specialized child nodes based on the kind of project we create; in this case a project with a nature of customplugin.projectNature.

Today’s task (a repeat of what I listed above) was:

Open the navigator in a perspective (doesn’t matter which one)

Create a Custom Project

Create a non-custom project. It should not appear in the custom navigator.

The challenge is: how to configure the Custom Navigator so that it will only display custom projects. In my never ending quest to write as little code as possible I will show you what to configure in plugin.xml and what code to add to ContentProvider to make it happen.

Supremely obvious point #1: without content a common navigator doesn’t display anything.
Supremely obvious point #2: you can configure a resource-based CNF navigator to do one of three things (if you can think of more, let me know or better yet write it up):

Display only certain resources,

Display resources in a custom way or

Some combination of 1 and 2.

We want to do #3: the navigator should only display custom projects and resources related to custom projects should be displayed in a custom way.

If we had wanted to display all of the top level resources in the navigator we would just define a viewerContentBinding of org.eclipse.ui.navigator.resourceContent. Since that content binding is already defined our work would be done. That however would be too easy and wrong for what we want to do (it is amazing how often easy and wrong go together).

We know that we can display custom projects and related resources in a custom way (we did that, remember?). Now we want to make sure that no matter how many projects we create the navigator will only display our projects our way (like fast food without the fat).

In order to do this we are going to take a few steps back and a few steps forward. We are going to:

Delete our existing navigator class (back one step)

Replace the existing navigator class with a CommonNavigator (back another step)

Attach a content binding to the viewer (which is actually already there, but we are changing it; back another step)

Configure a navigatorContent (which is also already there)

Define an object type to send into the content provider (called the triggerPoint): IWorkspaceRoot

Implement the content provider code to wrap our project and its children

Register a resource change listener in the content provider to update the viewer when new projects are added

Why change the triggerPoint from CustomProjectWorkbenchRoot to IWorkspaceRoot? Believe it or not, the CustomProjectWorkbenchRoot is overkill for what we want. In fact, using CustomProjectWorkbenchRoot will keep the navigator from working properly so in the tradition of YAGNI, we got rid of it. We may live to regret it depending on how complex this project gets, but for now out with the trash.

If a node of type ICustomProjectElement, and all of the custom project wrappers are this type, ask the object for its parent. The project will return the Workspace root, the child nodes will return the project or its custom parent node.

For all others return null (no parent)

Since the “all others” and IWorkspaceRoot return null we just need to check for the IProject and ICustomProjectElement.

The order of the methods above are out of sequence for the class, but in sequence for this explanation.

In inputChanged() someone has done something that we need to pay attention to. In this case, a new project was added (we haven’t coded for deletions yet). Just save the viewer reference; we’ll need it later. However, if the input has changed we need a way to determine what that change was. Enter resource change listeners.

[If you don’t know anything about event handling in Java, much less Eclipse, the following explanation is probably not going to make a lot of sense.]

For now, the easiest place to register a listener is in the ContentProvider constructor so I placed it there. Of course, whatever we register we should unregister so in dispose() we remove the resource change listener.

Almost too easy. Our simple navigator just needs to be told to refresh itself when a change occurs.

To summarize: when our input changes we save the viewer; when a resource changes we call resourceChanged() which refreshes the viewer.

Life is beautiful.

What Just Happened?

Now it is time for me to admit something: I hate beets (that is: the vegetable).

Well, more significantly, I have to admit it took a while for me to figure out how simple this truly was. I looked at examples, read posts, drank plenty of Guinness. Finally, I woke up one morning and thought Oh! Is that all it is?

What I found was that the examples did not do what I was trying to do (don’t you hate when that happens?). They always seem to use the pre-existing resourceContent binding in addition to other stuff which didn’t help me at all (well, it did actually help, but kept me confused for too many nights).

The moral of the story: use resourceContent if you need to show the existing resources in a standard way or with exceptions.

Don’t use resourceContent if you want to take full control over the navigator.

That might be too general and all encompassing, but, what the hell, what isn’t?

And of course all this may change as I add more functionality to fill the custom project with custom content. Stay tuned, boys and girls.