Here are some of the more noteworthy things available in e4 1.0 milestone build M2 (November 20, 2009) which is now available for download. See the build notes for details about bugs fixed and other changes.
Platform |
|||||||||||||||||||||||||||||||
Part save lifecycle | Parts can now declare themselves as being saveable by using SaveablePart. An example of this can be seen in the e4 contacts demo, in which changes to text fields can now be saved. | ||||||||||||||||||||||||||||||
Dirty notification | The e4 renderer will now automatically display and update the part's dirty state affordance as the underlying model changes. For example, in the e4 contacts demo changing a selected vCard's content will now cause the dirty affordance to be displayed in the part's tab. | ||||||||||||||||||||||||||||||
Keybindings |
The workbench model now supports multi-stroke keybindings. A keybinding can be added to
the model at the Application, Window, or Part and ties a key sequence to a command.
Examples are included in both the e4photo and contacts demo.
Key assist and different keybindings per platform or locale are not yet implemented. |
||||||||||||||||||||||||||||||
javax.inject annotation support | Context injection has been modified to support
the annotations defined in the upcoming javax.inject package.
Now in Java 5 or greater VMs we use annotations such as @Inject and
@Named to describe context elements to inject. The internal
injection processing has been updated to make use of these annotations, and
passes the open source annotation-based injection test suite found at
http://code.google.com/p/atinject/.
As a result of this work the dependency injection implementation has started to shape up
as an independent service. While the exact APIs are still under construction and will change,
we expect to make the |
||||||||||||||||||||||||||||||
New UI model structure | The UI model has been refactored to separate model data from the containment rules.
All of the core e4 UI code is written against the 'data' layer, allowing for greater
flexibility in how the client manages their model's containment, while retaining the ability
to use the existing renderers. For example the PartRenderingEngine will correctly manage the
context life-cycle for any UI Model element that inherits Context , regardless of what
the particular model element is.
The present iteration of the UI model predefines two containment models; one is part-based and the other is a capture of the legacy IDE containment structure. We expect that it will also be possible to create custom application-specific containment models that will still be supported by the rendering architecture: it will still automatically update labels, images, etc, when the model changes.
One of the nice side-effects of this new model is cleaner use of generics. In the
containment layers each container has a specific type that it can contain,
meaning that the java tooling will now correctly flag attempts to add elements to
invalid containers (e.g., adding a While the model will be changing over the next few milestones we expect that the basic structure will maintain this data/containment separation. |
||||||||||||||||||||||||||||||
e4 event bus |
e4 now has an event bus style architecture based on the
publish/subscribe pattern. This means a 'one stop shopping' approach for
E4 clients; any event we expect a client to be interested in
(UI model changes, part life-cycle events, etc) will be available through a
common mechanism simply by registering an event handler against the
appropriate topic.
There is already a publisher for UI model events and the internal e4 workbench code has all be modified to use the new event bus. For more information see the wiki. |
||||||||||||||||||||||||||||||
OpenSocial gadgets |
OpenSocial gadgets can now be opened as views in Eclipse. Gadgets are reusable
web UI components as defined in the OpenSocial Gadgets API Specification. At
this point, only parts of the specification are implemented, but many existing gadgets
already work.
Many social websites implement this specification and can host OpenSocial Gadgets, for example iGoogle, hi5, LinkedIn, MySpace, orkut, Friendster, Ning, XING and others. The "social" aspect of OpenSocial Gadgets, including access to user data and their network of "friends", is also not yet implemented in e4 - we have focused on the Gadgets part of the specification. The procedure to add a gadget is pretty simple:
If your gadget is customizable, you can use the View menu to edit its preferences on a dedicated property page. You can find more details, and a list of gadgets to try, on the e4 OpenSocial wiki page. Keep in mind that the implementation is in a very early stage. Many features of the OpenSocial Gadgets specification are still missing or are not fully implemented. |
||||||||||||||||||||||||||||||
XWT |
|||||||||||||||||||||||||||||||
ComboViewer | The ComboViewer of JFace
can be defined in the same way as ListViewer and
TableViewer using the standard JFace class.
|
||||||||||||||||||||||||||||||
Simplified JFace viewers | This milestone has simplified the declaration of JFace
viewer. The ILabelProvider and IContentProvider
are not needed any more.
Here is the code for TableViewer, <TableViewer input="{Binding Path=employees}"> <TableViewer.columns> <TableViewerColumn width="150" text="Name" displayMemberPath="name"/> <TableViewerColumn width="150" text="Age" displayMemberPath="age"/> </TableViewer.columns> <TableViewer.control.layoutData> <GridData horizontalAlignment="FILL" grabExcessHorizontalSpace="true"/> </TableViewer.control.layoutData> </TableViewer> Her is the code for ComboViewer, <ComboViewer input="{Binding Path=employees}" displayMemberPath="name"> And the code of ListViewer <ListViewer input="{Binding Path=employees}" displayMemberPath="name"> |
||||||||||||||||||||||||||||||
Viewer Filter | A new class ViewerFilter is provided
to define a filter in a JFace viewer. This class contains a collection of Condition
which is used as predicate to select the elements to display.
<TableViewer Name="TableViewer" input="{Binding Path=employees}" > This |
||||||||||||||||||||||||||||||
IObservable Management | A new IObservable management is implemented in XWT
for each UI resource unit. XWT keeps now all instances of IObservable. It allows developers
to get the IObservableValue and then modify observed values with automatically
notifications in UI and in behind data. The service is provided in the main class XWT :
IObservableValue XWT.getObservableValue(Object control, Object data, String path); |
||||||||||||||||||||||||||||||
Master/Detail support | XWT starts to provide a transparent "Declarative Data Binding"
solution to hide all complexity of JFace data binding. The master/detail presentation
is supported straightforward in the path expression of Data Binding. The expression language
is extended to complete the missing type in programming language.
For example, the element type of a collection is always missing in binary class in Java.
This information is necessary to build the Data binding chain in Mater/Detail pattern.
In the following example, we have a class <ListViewer name="master" input="{Binding Path=employees}" displayMemberPath="name"> The property "name" in the binding expression is prefixed by its type Employee and enclosed by parentheses. Here is the example Snippet017 of Jface Data binding ported in XWT:
|
||||||||||||||||||||||||||||||
Heterogeneous data model support | In the real application, data model can be mixed together
in the business model: Java Bean, Pojo, dynamic EMF, Web service, XML, database etc.
The previous release has supported most of them separately in one expression, data model
could not be mixed. This milestone removes this limitation, it provides a total transparent
Declarative Data Binding expression solution.
For example, if we have two classes: one in Java and another in EMF public class Author { where "content" can be an instance of Book class defined in EMF, which is a dynamic model with one attribute "title". In UI, if we just need to specify the binding in the same way, <Text text="{Binding path=content.(Book.title)}" /> |
||||||||||||||||||||||||||||||
Update Source trigger | This milestone integrates a new type UpdateSourceTrigger .
In addition, a new property "updateSourceTrigger" has been added in the class Binding
and therefore in data binding expressions. This class indicates when modifications
to the data binding source model will occur. Many UI elements have only one possible trigger,
such as check buttons. However text widgets have two possibilities: when the content gets changed,
or when the focus is lost.
<Text text="{Binding path=name,updateSourceTrigger=FocusOut}"> |
||||||||||||||||||||||||||||||
More operators in conditions | The following operators have been added in Condition
and all classes of Trigger to extend the expression support:
|
||||||||||||||||||||||||||||||
Examples and Tests |
|||||||||||||||||||||||||||||||
Modeled UI Testing Infrastructure | New abstract test classes has been added to make the testing of e4-based
applications easier. Concrete subclasses can provide their own model XMI files and/or renderers to
customize the tests. See HeadlessStartupTest and its subclasses in the
org.eclipse.e4.ui.tests bundle.
|
||||||||||||||||||||||||||||||
|
The above features are just the ones that are new since the previous milestone build. Summaries for earlier 1.0 milestone builds: