Sapphire: the first attempt was EMF-based.
JAXenter speaks with Konstantin Komissarchik, initial committer of the proposed Eclipse Sappphire UI project.
Sapphire is a newly-proposed Eclipse project that aims to ease UI development. JAXenter caught up with initial committer Konstantin Komissarchik to find out how Sapphire fits in with e4, EMF, and why Oracle is helping to develop Sapphire as an Eclipse project…….
JAXenter: In your opinion, what are the current pitfalls of writing Java desktop UI?
Konstantin Komissarchik: Regardless of which widget toolkit you use, the API that the developers are working with are designed to optimize flexibility and to make as few assumptions as possible. This is great if you are developing something truly unique, but much of the UI that is written on the daily basis doesn’t benefit from this flexibility. In fact, it is hurt by it. Not only does it take a lot of work to implement simple screens, but consistency is very difficult to achieve. Developers implement different UI patterns for solving similar problems. An incredible amount of time is spent achieving consistency on such mundane items as layout, button widths and margins.
It’s amazing how much UI code must be written just to present a text field with a browse button, make sure that data binding happens and validation problems are surfaced. That code becomes a product’s maintenance liability. Even the best developers fall into traps of having UI components talk directly to other UI components. The resulting web of event handlers will be next to impossible to maintain and evolve in the future.
On top of that, the code that is written is tied to a particular widget toolkit. If you want to migrate your app from Swing to Eclipse RCP, you have to re-write all of the UI from scratch. If you have a desktop app that you are happy with, but you want to add a browser-based client you again have to start from scratch.
JAXenter: What are the benefits of replacing a widget with a property editor in UI, as Sapphire does?
Konstantin Komissarchik: The benefit of Sapphire‘s approach is that the developer tells the system what he wants to accomplish rather than how to do it. Using Sapphire, the developer says “I want to edit LastName property of the person object.” Using widget toolkit like SWT, the developer says “create label, create text box, lay them out like so, configure their settings, setup data binding and so on.”
With Sapphire, similar data patterns will get surfaced in the UI in a similar manner. Not only that, but the UI definition is inherently more portable. Since Sapphire doesn’t prescribe the exact manner in which a given property is to be edited, the implementer of a renderer can choose an approach that makes the most sense for the platform they are targeting. The same UI definition can produce an SWT application for rich desktop experience and a Web application designed to work in an old browser under bad network conditions.
JAXenter: How do Sapphire and e4’s declarative approaches to UI specification, differ?
Konstantin Komissarchik: An e4 UI definition composes UI out of individual widgets, while a Sapphire UI definition composes UI out of property editors. Both have their place. The e4 project will produce the next generation of Eclipse RCP, with ability to handle arbitrarily-complex UI requirements. Sapphire will sit on top of that and will provide a higher-level language appropriate for the majority of situations where requirements are more mundane.
JAXenter: For Sapphire, why did you opt out of using EMF as a modeling framework?
Konstantin Komissarchik: We spent a lot of time debating this internally. In fact, the first attempt was EMF-based. Ultimately, it came down to ease of use and having a shallow learning curve. Our goal with Sapphire is to improve how developers write UI. While our approach centers around a model for the data, we are fundamentally not in this to promote modeling. It comes down to doing the best to leverage the knowledge that a typical Java developer would already poses. We do not want to have learning a complicated modeling framework to become a barrier to adoption. For instance, Sapphire’s modeling framework uses Java annotations and will appear familiar to anyone who has done JAXB or JPA development.
At the same time, we do not want to exclude developers who are already invested in EMF from getting the benefits of Sapphire. We are interested in exploring ways in which Sapphire can leverage existing EMF models.
JAXenter: The initial code contribution for Sapphire comes from Oracle’s Enterprise Pack for Eclipse. What is the motivation for Oracle developing Sapphire as an Eclipse project?
Konstantin Komissarchik: Multiple motivations have led to this move. For one, OEPE leverages tooling that comes from Eclipse projects to create a complete solution for Oracle customers. If Sapphire is available to these projects, then we could see even better tooling for standard technologies as projects become able to produce quality UI quicker. This, of course, directly benefits Oracle.
We also realize that we cannot by ourselves take Sapphire to its full potential. For instance, we currently only have a renderer for SWT. We’d love to work with other members of the Eclipse community to build a library of quality renderers as that will increase the value of Sapphire for everyone.