IntroductionMany tutorials and quite a number of books describe how to get started in Eclipse plug-in development. It is only when trying to apply all of this new found knowledge to real world business applications that things get complicated.
Gradual increase of complexity
The main problem during development of large systems is that all parts evolve in parallel: that database schema, the business logic on the servers, the EJB connection code and the RCP client. So it's time to think about what John Gall, much quoted author on System Theory, wrote:
That is the inspiration for this blog post: you have to start simple and get it to work, then evolve from there. In this blog entry I will share how with a little forethought you can make you RCP client application easier to develop and test. With RCP client application I mean a front end for a large server based business application where multiple users access real time data using an Eclipse RCP based client. All business logic takes place on the server, the client provides a view to the current data and allows users to modify that data.“A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.”
Basics: Split between UI and Core plug-insA good practice is to divide up your functionality in two plug-ins: one to handle most logic, called the Core plug-in, and another containing all code that requires a UI, called the UI plug-in. Only the UI plugin has a dependency on the eclipse GUI framworks: org.eclipse.swt, org.eclipse.jface, org.eclipse.ui and org.eclipse.ui.workbench.
NullController PatternThe split between UI and Core is also called the Model View Controller or MVC pattern. Basically the UI subscribes to data updates and translates UI events that modify data into method calls to the controller. In Java terms: the controller in Core has subscribe() and unsubscribe() methods that take an application specific listener interface as parameter.
The trick is to make the location of the controller indirect via a Factory, so it can evolve in complexity over time.
AbstractControllerThe AbstractController includes the code to handle subscribe() and unsubscribe() of one or more views. It probably also contains the code to broadcast new or changed data to the views.
NullControllerThe NullController implementation is the simplest possible form of the interface. All action method calls do nothing and all query methods return either null or, when collections, empty instances (so all iterators in views work).
With this controller you can work on the UI view and button layout and do simple developer testing for button and menu enablement.