Eclipse RCP – Missing Controllers
It has been more than a year that a switched from working ON the JDeveloper platform to working WITH the Eclipse platform.
There is of course a lot to learn but that’s the fun part of our job.
The Eclipse platform however has one flaw that keeps bothering me and makes the development much harder: controlling and handling actions.
Some basic information about the JDeveloper Platform.
JDeveloper uses a MVC (Model/View/Controller) pattern. Each editor and dockable window (called Views in Eclipse) are Views (the V in MVC). It is possible to create a View within a View and the top level window (Workbench Window in Eclipse) is also a View.
Each View has a Controller and since the platform knows about the View hierarchy, it knows the hierarchy of Controllers.
The actions in both platforms are used by the menus and toolbars. In both cases, an action has a text, an icon, a mnemonic and it can be enabled/disabled and checked/unchecked.
In Eclipse, the action is also responsible for “acting” (do something when the menu is activated) and other pieces of code (listeners usually) are responsible for “updating” (enable or disable the action)
In JDeveloper, the controllers are responsible for both the “acting” and “updating”.
This may seem like a detail but a first consequence is that it is much easier to share a menu like “Delete” or “Properties”.
When the user activates an action, JDeveloper will get the controller from the active view (the one that has the focus) and it will ask that controller to handle the action. If the controller does not know what to do with the action, JDeveloper will try again with the parent view then to the grand-parent…
Each View has therefore the possibility to determine what to do with an action.
The second consequence is even more important. Since the platform controls who gets the control of the action, it knows who to ask about the status of the action.
Since most actions are most of the time hidden in a menu there is no point in constantly updating the state of the action whenever something happens. JDeveloper will ask the controllers to update the actions when the menu is pulled down.
This is the most important advantage compared to Eclipse which requires writing a cascade of listeners to update the actions.
Imagine that you write an email client and you have one menu (action) that marks an email as Read or Unread.
You have one window that displays the folders and one window that displays the messages in the selected folder.
With Eclipse, you would have to write a first listener that tracks the current window. When the current window changes to one of the two windows, you add another listener that tracks the selection within the current window. You must of course not forget to remove the selection listener on the previous window.
If the current window is not one of your two windows, you must disable the action.
When the selection changes within the window, your must determine if the selection is a folder or a message.
If the selection is a folder, you must enable the action and change the text to “Mark All Read” (or Unread but let’s keep it simple). If the selection is a message, you enable the action and the text becomes “Mark Read”.
With JDeveloper, you don’t need listeners. You have one controller for the Folder window and one for the Message window and they will be asked to update the action when necessary or to do something when the action is activated.
In conclusion, your code is much simpler with the MVC architecture combined with the lazy update mechanism since you don’t need all those listeners. It is also much cleaner since you don’t need to share code for two unrelated actions.
Kudos to Jose Cronembold for implementing the MVC architecture in JDeveloper and to Armand “Jojo” Dijamco for implementing the lazy update of actions.