Friends of Eclipse,
Eclipse is an open source community that benefits millions of developers around the world each and every day! During the month of September, we are asking you to give back to our wonderful open source community. All donations will be used to improve Eclipse technology. Your contribution counts!
We thank you for this gesture, and for giving back to our community.
Little has changed in the way Java desktop UI is written since the original Java release. Technologies have changed (AWT, Swing, SWT, etc.), but fundamentals remain the same. The developer must choose which widgets to use, how to lay those widgets out, how to store the data being edited and how to synchronize the model with the UI. Even the best developers fall into traps of having UI components talk directly to other UI components rather than through the model. Inordinate amount of time is spent debugging layout and data-binding issues.
Sapphire aims to raise UI writing to a higher level of abstraction. The core premise is that the basic building block of UI should not be a widget (text box, label, button, etc.), but rather a property editor. Unlike a widget, a property editor analyzes metadata associated with a given property, renders the appropriate widgets to edit that property and wires up data binding. Data is synchronized, validation is passed from the model to the UI, content assistance is made available, etc.
This fundamentally changes the way developers interact with a UI framework. Instead of writing UI by telling the system how to do something, the developer tells the system what they intend to accomplish. When using Sapphire, the developer says "I want to edit LastName property of the person object". When using widget toolkits like SWT, the developer says "create label, create text box, lay them out like so, configure their settings, setup data binding and so on". By the time the developer is done, it is hard to see the original goal in the code that's produced. This results in UI that is inconsistent, brittle and difficult to maintain.
Describe semantics of the data that UI will edit using Java annotations. Model implementation classes are generated on the fly. More details in documentation.
Use included XML binding facilities to describe how model should read and write data from XML. Take advantage of integration with WTP XML edtior to create sophisticated multi-page editors with live bi-directional synchronization between design and source views.
Combine information from multiple models into an integrated model. Bring together information
from many files.
Describe how to present the model in UI in via a simple XML file and let Sapphire handle the rest. Embed Sapphire UI anywhere you can create an SWT control. Editors, views, wizards, dialogs, etc. all can benefit from Sapphire.
Start making a list of stuff that you can now forget about...
Currently only SWT presentation is available, but Sapphire UI definitions are not tied to a particular toolkit. Other presentations such as Swing, HTML or Flash are possible in the future either from this project directly or from adopters.
Back to the top