Eclipse has a strong reputation as a reliable and high-quality platform, the result of an agile development process with unit testing and refactoring as well as conceptualization of a flexible and extensible architecture. The need for reliable code can be satisfied using the principles and tools that have proved successful for Eclipse. As members of the Eclipse team, we have transferred these principles into the realm of Web universal interface (UI) development.
The part of the Eclipse platform that provides the widgets (the atomic building blocks of user interfaces, like buttons, text fields, etc.) is SWT, for Standard Widget Toolkit. SWT is designed to be as thin as possible and is, in fact, nothing more than a direct bridge to the native widgets of the OS. For developers using SWT is just coding in Java.
An analogous widget set for Web UI development is W4T, for WWW Windowing Toolkit. Like SWT, it hides the specifics of the target platform from the developer behind an all-in-Java API. The target client in this area is, of course, a Web browser, and the specifics consist primarily in the dialects of the likes of HTML or JavaScript that each of the browsers understands and renders correctly. (In contrast to SWT, W4T has to do more work because of the distributed nature of Web applications and the statelessness of HTTP.
In UI development, there are many recurring tasks (like displaying a domain model structure on a tree viewer or in a table) that result in ever-the-same widget constructions. To facilitate coding in such situations, the Eclipse platform provides another tool kit for programmers: JFace. It employs SWT widgets in reusable components like viewers that can be easily configured to display domain models. The widget set (SWT) and the application tool kit (JFace) are clearly separated, and both are still a manageable size. It is surprisingly simple to learn to use them.
When starting to build complex applications with W4T, we faced the decision of whether we should try to work as much functionality and convenience components as possible into the core library itself or if we should divide functionality into several layers.
Learning from the Eclipse project, we decided not to put viewers and other complex components into the set of basic widgets. We avoided dependencies from the lower to the higher level and also aimed to clarify the workings of the higher-level components by describing them in tutorials and examples that are available in source code.
A clear separation of layers is important for the reliability of the UI code in several respects: First, using a relatively small API on each layer makes it easier to find good solutions to problems on that level (or to find that the problem actually belongs to a different level) and increases the chances to end up with code that is easy to extend and debug. Second, if developers had the opportunity to ("quick and dirty") introduce low-level code into passages that handle application-specific details, possible interference of that code with the smooth working of the run-time would impair the overall functioning of the system. This results almost inevitably in bugs that are difficult to find. The separation of layers reduces this risk by hiding away the low-level elements (platform-dependent code with SWT, HTML and scripts with W4T) from the higher-level application code.
Apart from creating the user interface layout and connecting views and controls to the business logic layer, developers face a third challenge when building a complex user interface for an application. Let us call this the "UI logic" of the application. It consists of all synchronization and interaction that takes place between UI parts and is not immediately involved with the business logic.
Think of an e-mail client as an example. The UI of such an application has several parts: a tree that represents inbox, outbox and other folders; a list of e-mails in the currently open folder; and a preview area that shows the currently selected e-mail as well as toolbars and drop-down menus. Depending on the type of the currently selected folder or the currently selected e-mail, toolbar buttons may be enabled or disabled. The Send button, say, will be disabled when the inbox is shown and enabled when displaying mail that is in the outbox. You click on a button called "Show only new mail" and several folders are excluded from the tree and the list of e-mails is filtered to show only the latest mails. Such behavior is called UI logic.
Of course, implementing that logic is much more challenging with complex UIs (like the e-mail client) than with a traditional Web UI that has a flat structure with just some text fields and one submit button on it. Now, with widget-based Web development, complex user interfaces as we know them from desktop applications make their entry into the realm of Web UIs. And this is where UI logic and the techniques developed to handle it come in. We mention here only two of them briefly: refactoring and test-driven development.
Once the UI is entirely built with Java components (as is the case with widget-based approaches), all source code manipulation tools that come with Eclipse can be applied to the code that describes the Web UI exactly as they are to any other Java code.
For example, think of the type name of a custom widget you have created and used extensively in your application. There are now many places in the code where this type name is referenced. Renaming the component would require changing all these code passages, with the risk of forgetting one of them. With the Rename refactoring in Eclipse, all this is done automatically. This saves time, makes it possible to concentrate on more important aspects of the code and encourages a programming style that uses variable names to get the code self-documenting. And everything that adds to the readability of the code is at the same time a gain in maintainability and reliability.
Based on the tools already contained in the Eclipse JDT (and in expectation of the public refactoring APIs that will come with the 3.0 release), we have created additional refactorings for more GUI-related tasks: for instance, extracting a custom panel with several components placed on it out of the component tree of a container, or transforming a container into a top-level container.
Jochen Krause is co-founder and managing director and Leif Frenzel is senior architect at Innoopract Informationssyteme GmbH (Karlsruhe, Germany).
See related chart
