Dan:
Your point about views, could you elaborate a bit more? I'm not certain what you're after -- view to view synchronization? Eclipse doesn't have a generic solution, only a few specific cases (resource delta notifications, JDT element changes, etc). I assume this was because they wanted to avoid the "notify the world" trap that so many OO frameworks seem to fall into. What solution did you ultimately decide upon to solve your problem?
Here's a brief run down of what I was trying to do. I wrote a series of plugins that automate change management to a large scale database (teradata). Any change to any component of the ETL (extraction transformation load) process effects other components of the process. For example a change to a table name requires that all scripts that reference that table must also be changed.
So the plugins provide a view for source files, a view for scripts, and a view of databases. The source file view and script view are tied to the resource selection in the navigator view, and the database view has an action that allows you to specify a connection to a database. From these views users are able to interact with the components and make changes.
The last view is a changes view. It's a lot like the error log or task view, but contains a list of running changes that happen as a result of user actions. The changes are not directly tied to user action, as a user modification to a value might cause MANY rippling changes throughout the ETL process.
So what I want to know is what is the best way to access the underlying model of the change view from the inside the other views (so that when a user modification creates a set of changes the view can add the changes to the change view model).
I hope that wasn't too confusing. This is what I'm doing right now, and I think that there are probably a lot better ways to do it, but I can't find them.
Here's some code (off the top of my head, but I think its right)
The "lessthan" is because java ranch thinks they are html escape codes and keeps rejecting this post (wierd).
That seems like either a very involved way to get a view, or that I don't understand some fundamental concept. What I meant in my earlier criticism of the book is that I would have liked if there was some more background about how all the parts of the API fit together. There is some discussion of these issues, but I would have loved a chapter with a high level explanation of the major components of the API and how they all fit together. It would save me a lot of fumbling around reading the API trying to figure out what componets of the API I need to use.
Maybe not a fair criticism, as I'm doing some fairly involved things with Eclipse, but just something I was fighting with.
Michael Crutcher
