New in Ext GWT 3.0

JavaScript libraries, Ext JS and Ext GWT is known, among other things, one of the best sets of visual components — how to design and cross-browser compatibility, and stability. Because the hands themselves drawn to any project to add Ext GWT and replace your boring uglovye widgets on lovely shapes and Windows.

However, the integration of Ext GWT and GWT still left much to be desired — in fact, the second version of Ext GWT fully displaces all funds layout GWT, offering its own APIs for everything down to event handling. So for the third version of the library available now in the form of developer preview, the developers of Sencha actively rewriting the script the legacy Ext JS using patterns and idioms, adopted in GWT. The main expected advantage — more correct integration with GWT and, as a consequence, a more compact and optimized code interface: generation and obfuscation of JavaScript and CSS is happening on stage, GWT-compile, using the deferred binding mechanism, due to which the excluded code fragments that are not used in the current project.

Implementation of widgets using Appearance

One of the patterns copied from GWT, was the Appearance that allows you to select a widget, its layout, style and binding logic into independent and replaceable parts. This approach allows to easily change the styles and themes of widgets, and even their markings — for example, to use as a DOM-implementation of the button, or div, or button. Here is a simple example of applying a pattern Appearance for a simple div-buttons, which can change text and icon:

the

public interface Appearance {
void render(SafeHtmlBuilder sb);
void onUpdateText(XElement parent, String text);
void onUpdateIcon(XElement parent, Image icon);
}

public static class DefaultAppearance implements Appearance {

public interface Style extends CssResource {

String testButton();

String testButtonText();

String testButtonImage();
}

public interface Resources extends ClientBundle {
@Source("DefaultAppearance.css")
Style Style();
}

public interface Template extends XTemplates {
@XTemplate(source = "DefaultAppearance.html")
SafeHtml template(Style Style);
}

private final Style Style;
private final Template template;

public DefaultAppearance() {
this((Resources) GWT.create(Resources.class));
}

public DefaultAppearance(Resources resources) {
this.style = resources.style();
this.style.ensureInjected();
this.template = GWT.create(Template.class);
}

@Override
public void onUpdateIcon(XElement parent, Image icon) {
XElement element = parent.selectNode("." + style.testButtonImage());
element.removeChildren();
element.appendChild(icon.getElement());
}

@Override
public void onUpdateText(XElement parent, String text) {
parent.selectNode("." + style.testButtonText()).setInnerText(text);
}

@Override
public void render(SafeHtmlBuilder sb) {
sb.append(template.template(style));
}

}

A nested interface Style is the style of the rendering of the component. By default it is associated with an external file DefaultAppearance.css — this link is specified in the Resources interface. Finally, the third sub-interface, the Template represents the markup of the component, and by default associated with the external file DefaultAppearance.html. Designer DefaultAppearance object, you can override the interface implementation Resources, thus replacing the style or theme of the component. Similarly you can change the template, or even the whole object of DefaultAppearance whole — widget enough to know the simple interface Appearance to delegate setting, or event handling.

In the end, Ext GWT gives us three extension points through which we can affect the display of the widget: changing its CSS style, HTML markup, or completely overriding the object Appearance and the mechanism by which it interacts with the DOM to render the widget. Due to the pattern of Appearance all of these aspects are carefully separated from each other.

JavaBean-style objects as a data model

Finally, it will be possible to abandon the ModelData interface, which it used to wrap any JavaBean-style objects, so they can serve as data models. In Store and Loader may be the use of any objects that are not associated with any contracts of the interfaces and not extend specialized classes. All this is achieved through the magic of deferred binding code for access to specific fields of the object is generated at the stage of GWT compilation. So far, the examples of the new API for working with storages and loaders do not exist, but innovation is demonstrated by the example of other innovation — redesigned the template engine XTemplate:
the

interface TemplateTest extends XTemplates {
@XTemplate("<div><span>{name}</span></div>")
SafeHtml renderCustomer(Customer customer);

@XTemplate(source="template.html")
SafeHtml renderCustomerExternal(Customer customer);
}

...

TemplateTest template = GWT.create(TemplateTest.class);
SafeHtml html = template.renderCustomer(customer);

Field of any transmitted object can now be used directly in the body of the template — so, the code uses the field customer.name. To test this code, I didn't even have to declare any meta-interfaces — everything you need magically generated at compile time. The pattern itself, as can be seen from the example, either in the string-the annotation value XTemplate, or in an external file whose name is placed in the source field of the same annotation. The result of applying the template is safe HTML — safe in the sense that the resulting SafeHtml accurately refers to the possible sources of XSS attacks in the given fields and values.

UiBinder: declarative layout interface

Another long-awaited feature — integration with existing GWT 2.0, even with the arrangement of the layout of the interface in XML UiBinder. It allows you to bring in an external XML file layout components, making it declarative and structured and separated from the logic interface, written in Java code. Still UiBinder was only available for standard widgets and containers GWT, but now the Ext GWT developers are actively working on integration with it's own components. The main problem, from-for which the API is still not fixed and even put in a separate jar file, is the complexity of configuring containers using LayoutData — the current implementation does not allow UiBinder to write your own parsers for attributes of XML markup. The developers of Ext GWT and GWT are now working on reconciling changes in GWT that will make it possible. Yet, there are the following option (the root tags for readability omitted):

the

<border:BorderLayoutContainer pixelSize="800, 400">
<border:north layoutData="size:100; margins: 0 0 5 0">
<gxt:ContentPanel />
</border:north>
< border:west layoutData="size:150; margins: 0 0 5 0">
<gxt:ContentPanel />
</border:west>
<border:center layoutData="0">
<gxt:ContentPanel heading="BorderLayout UiBinder Example" />
</border:center>
<border:east layoutData="size:150; margins: 0 0 0 5">
<gxt:ContentPanel />
</border:east>
<border:south layoutData="size:100; margins: 5 0 0 0">
<gxt:ContentPanel />
</border:south>
</border:BorderLayoutContainer > 

It is easy to see that the proposed syntax fields layoutData something like CSS styles in attributes. For this mechanism to work you need to connect to the library project gxt-uibinder-3.0.0-SNAPSHOT.jar and uibinder-bridge-2.3.0-SNAPSHOT.jar. However, I must say that I did not get to test this example — GWT steadfastly refused to convert the unknown to him the contents of the layoutData object BorderLayoutData.

Opinion

To other small Goodies in the new version include:
the

the
• is unified with the GWT event handling mechanism — there are no listeners, the standard handlers;
the
• translated from Flash to JavaScript charts — examples of the application distribution file Ext GWT Explorer, as usual, impressive militantly and performance;
the
• some simplifications in containers and layouts containers LayoutContainer is now firmly associated with the layout Layout (RowLayoutContainer, BorderLayoutContainer, etc.), which facilitates their configuration and thus provides type safety.

In conclusion, the current version of Ext GWT 3.0 works in conjunction with GWT 2.3.0, and requires at least Java 1.6 for compilation to succeed, due to including the requirements of the GWT. Changed the root library package — in the spirit of the recent rebranding of the company com.extjs was replaced by com.sencha. The developers promise to release new developer preview again in a few weeks, but note that these versions still only show new features and still not fixed the API, and therefore not recommended for use in the development.

Links

the

the
• the Ext GWT 3.0 Appearance Design
the
• the Ext GWT 3.0 Developer Preview 1
the
• the Ext GWT 3.0 Developer Preview 2

Article based on information from habrahabr.ru