Wednesday, July 12, 2006

Response to comments and status on upcoming articles


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