This is a good question, however, since it is allowed, I might as well do it if I please. One might, if so inclined, expand a class in the Package Explorer and the delete a specific function or member or whatever, no problem at all.
There is however a little something one should be aware of. In case this operation is performed on a class that is not currently open in an editor, there will be no going back - no undo will be available!
I have discovered this little glitch while trying to work with the new Common Navigator framework that was added to the 3.2. After reading the excellent tutorials on the subject, I have tried to create a view very similar to the Package Explorer, but for my own file types. In order to show the contents of my file, the view should be aware of my model. In case the file is also being edited in the editor, the Common Navigator view should be updated to reflect the current state of the model and correctly display the model in the tree. In the tutorial example this is done via the file system - each time the file is saved in the editor the navigator view is notified and updated. This is OK, for the example, but it is very inconvenient when working with a real model. Also, this is not a way Package Explorer behaves, a function appears there as soon as it is written even before the file is actually saved.
A friend I have been working with has suggested to put a model in a singleton container, so that it would be accessible from both a view and an editor, and implement some kind of notification mechanism to track the changes. That eliminated the need to reload the file from the Navigator view each time a change was made. Everything looked really good.
Until we started to implement the actions we wanted to perform on our model elements from the Navigator View. There we discovered that it was impossible to undo the operation that was performed on the model when the editor was closed, since that's where our command stack has resided. The only solution we saw was to move the command stack from the editor to the same singleton and thus allow to undo the performed operations from both the editor and the Navigator view.
During our attempts to determine whether this was a wise decision, we asked ourselves how did this work in the Package Explorer? Well, the problem was there too. The undo for operations on the file contents did not work, unless an editor was open, and even then it only worked from the editor and not from the view itself.
Unfortunately, we did not yet have time to go deeper into the code of the Package Explorer to understandit's inner workings. We also did not find a bug on this in the list. So meanwhile, the question remains: where to hold the model and the command stack so that both actions and their undo are available from both the Editor and the Navigator.
If, by any chance you know someone who knows the answer to these questions, please use the comments. That's what they are there for, you know :)
The paradox of insular language
7 months ago
2 comments:
Have a look at ISaveablesSource and Saveable, and the providesSaveables flag in your navigatorContent extension definition.
Not sure exactly how this ties into undo though.
I think I might have found your undo problem.
In short, undo/redo is not enabled properly if no resource is selected in the viewer. You can easily try this. Create a file, and you should see undo available.
Then de-select (control-click) the selected resource in the view, having only the view selected and the undo should no longer be enabled.
The problem is the action associated with the undo/redo is only enabled when something is selected which is not correct. I will post my proposed solution to the platform newsgroup.
Post a Comment