New in Ext GWT 3.0
The Ext JS and Ext GWT JavaScript libraries are known, among other things, for one of the best sets of visual components, both in design and cross-browser compatibility, and in work stability. Therefore, the hands themselves are drawn to any project on GWT, add Ext and replace boring Google widgets with cute 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 completely replaces all the GWT interface layout tools, offering its own APIs for everything up to event handling. Therefore, for the third version of the library, which is now available in the form of a developer preview , the developers from Sencha actively rewrite the Ext JS scripting legacy using the patterns and idioms adopted in GWT. The main expected advantage is more correct integration with GWT and, as a result, more compact and optimized interface code: JavaScript and CSS are generated and obfuscated at the GWT compilation stage, using the deferred binding mechanism, thereby eliminating code fragments that are not used in current project.
One of the patterns adopted from GWT was Appearance, which allows you to select a widget, its layout, style and connective logic into independent and replaceable parts. This approach allows you to easily change the styles and themes of widgets, and even their markup - for example, use either a div or a button as a DOM implementation. Here is the simplest example of applying the Appearance pattern to a simple div button, where you can change the text and icon:
The nested Style interface represents the component's drawing style. By default, it is associated with the external DefaultAppearance.css file — this connection is specified in the Resources interface. Finally, the third nested interface, Template, represents the component markup, and is linked by default to the external DefaultAppearance.html file. In the constructor of the DefaultAppearance object, you can override the implementation of the Resources interface, thus replacing the style or theme of the component. Similarly, you can change the Template template, or even the entire DefaultAppearance object — a widget can only know the simple Appearance interface to delegate to it the setting of parameters or event handling.
')
As a result, Ext GWT gives us three extension points through which we can affect the widget display: by changing its CSS style, HTML markup, or by completely redefining the Appearance object and the mechanism by which it interacts with the DOM to render the widget. Thanks to the Appearance pattern, all these aspects are neatly separated from each other.
Finally, it will be possible to abandon the ModelData interface, in which it was necessary to wrap any JavaBean objects earlier so that they can serve as data models. In Store and Loader, it will be possible to use any objects that are not bound by any interface contracts and that do not extend specialized classes. All this is achieved through the magic of deferred binding - the code for accessing specific fields of an object is generated at the GWT compilation stage. So far, there are no examples of an API for working with repositories and loaders, but the innovation is demonstrated by the example of another innovation - the reworked mechanism of the XTemplate templates:
The fields of any transferred object can now be used directly in the template body — for example, the customer.name field is used in the above code. To test this code, I did not even have to declare any meta-interfaces — everything that is needed is generated magically at the compilation stage. The template itself, as can be seen from the example, can be contained either in the string-value of the XTemplate annotation, or in an external file whose name is placed in the source field of the same annotation. The result of applying the template becomes secure HTML - safe in the sense that the resulting SafeHtml accurately handles possible sources of XSS attacks in the transmitted fields and values.
Another long-awaited feature is integration with the existing interface markup mechanism in XML, UiBinder, with GWT 2.0. It allows you to put the layout of components into an external XML file, making it declarative and structured and separating it from the interface logic written in Java code. Until now, UiBinder has been available only for standard GWT widgets and containers, but now Ext GWT developers are actively working on integrating their own components with it. The main problem, due to which the API has not yet been fixed and even submitted to a separate jar file, is the complexity of configuring containers using LayoutData - the current implementation of UiBinder does not allow you to write your own parsers for XML markup attributes. The developers of Ext GWT and GWT are now in the process of agreeing on changes to GWT that will make this possible. For now, the following option is offered (root tags are omitted for readability):
It is easy to see that the proposed syntax for the layoutData field is somewhat similar to CSS styles in attributes. For this mechanism to work, you need to connect to the project libraries gxt-uibinder-3.0.0-SNAPSHOT.jar and uibinder-bridge-2.3.0-SNAPSHOT.jar. However, I must say that I did not manage to test the above example - GWT stubbornly refused to convert the contents of the layoutData unknown to it into a BorderLayoutData object.
For other minor amenities in the new version of the library include:
In conclusion, I note that the current version of Ext GWT 3.0 works in conjunction with GWT 2.3.0, and requires at least Java 1.6 for successful compilation, which is also due to the requirements of GWT itself. The root package of the library has also changed - in the spirit of the recent rebranding of the com.extjs company, it has been replaced by com.sencha. The developers promise to release new versions of the developer preview once every few weeks, however, they note that these versions so far only demonstrate new features and the API that has not yet been fixed, and therefore are not recommended for use in development.
However, the integration of Ext GWT and GWT still left much to be desired - in fact, the second version of Ext GWT completely replaces all the GWT interface layout tools, offering its own APIs for everything up to event handling. Therefore, for the third version of the library, which is now available in the form of a developer preview , the developers from Sencha actively rewrite the Ext JS scripting legacy using the patterns and idioms adopted in GWT. The main expected advantage is more correct integration with GWT and, as a result, more compact and optimized interface code: JavaScript and CSS are generated and obfuscated at the GWT compilation stage, using the deferred binding mechanism, thereby eliminating code fragments that are not used in current project.
Implementing widgets using Appearance
One of the patterns adopted from GWT was Appearance, which allows you to select a widget, its layout, style and connective logic into independent and replaceable parts. This approach allows you to easily change the styles and themes of widgets, and even their markup - for example, use either a div or a button as a DOM implementation. Here is the simplest example of applying the Appearance pattern to a simple div button, where you can change the text and icon:
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)); } } The nested Style interface represents the component's drawing style. By default, it is associated with the external DefaultAppearance.css file — this connection is specified in the Resources interface. Finally, the third nested interface, Template, represents the component markup, and is linked by default to the external DefaultAppearance.html file. In the constructor of the DefaultAppearance object, you can override the implementation of the Resources interface, thus replacing the style or theme of the component. Similarly, you can change the Template template, or even the entire DefaultAppearance object — a widget can only know the simple Appearance interface to delegate to it the setting of parameters or event handling.
')
As a result, Ext GWT gives us three extension points through which we can affect the widget display: by changing its CSS style, HTML markup, or by completely redefining the Appearance object and the mechanism by which it interacts with the DOM to render the widget. Thanks to the Appearance pattern, all these aspects are neatly separated from each other.
JavaBean objects as data models
Finally, it will be possible to abandon the ModelData interface, in which it was necessary to wrap any JavaBean objects earlier so that they can serve as data models. In Store and Loader, it will be possible to use any objects that are not bound by any interface contracts and that do not extend specialized classes. All this is achieved through the magic of deferred binding - the code for accessing specific fields of an object is generated at the GWT compilation stage. So far, there are no examples of an API for working with repositories and loaders, but the innovation is demonstrated by the example of another innovation - the reworked mechanism of the XTemplate templates:
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); The fields of any transferred object can now be used directly in the template body — for example, the customer.name field is used in the above code. To test this code, I did not even have to declare any meta-interfaces — everything that is needed is generated magically at the compilation stage. The template itself, as can be seen from the example, can be contained either in the string-value of the XTemplate annotation, or in an external file whose name is placed in the source field of the same annotation. The result of applying the template becomes secure HTML - safe in the sense that the resulting SafeHtml accurately handles possible sources of XSS attacks in the transmitted fields and values.
UiBinder: declarative interface layout
Another long-awaited feature is integration with the existing interface markup mechanism in XML, UiBinder, with GWT 2.0. It allows you to put the layout of components into an external XML file, making it declarative and structured and separating it from the interface logic written in Java code. Until now, UiBinder has been available only for standard GWT widgets and containers, but now Ext GWT developers are actively working on integrating their own components with it. The main problem, due to which the API has not yet been fixed and even submitted to a separate jar file, is the complexity of configuring containers using LayoutData - the current implementation of UiBinder does not allow you to write your own parsers for XML markup attributes. The developers of Ext GWT and GWT are now in the process of agreeing on changes to GWT that will make this possible. For now, the following option is offered (root tags are omitted for readability):
<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 5 0 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 for the layoutData field is somewhat similar to CSS styles in attributes. For this mechanism to work, you need to connect to the project libraries gxt-uibinder-3.0.0-SNAPSHOT.jar and uibinder-bridge-2.3.0-SNAPSHOT.jar. However, I must say that I did not manage to test the above example - GWT stubbornly refused to convert the contents of the layoutData unknown to it into a BorderLayoutData object.
Conclusion
For other minor amenities in the new version of the library include:
- event-handling mechanism unified with GWT - no listeners, standard handlers;
- Graphics translated from Flash to JavaScript — examples from the Ext GWT Explorer application distributed in the distribution, as usual, are impressive with their lushness and speed;
- Some simplifications in containers and layouts — LayoutContainer containers are now tightly tied to Layout layouts (RowLayoutContainer, BorderLayoutContainer, etc.), which somewhat simplifies their configuration while ensuring typical security.
In conclusion, I note that the current version of Ext GWT 3.0 works in conjunction with GWT 2.3.0, and requires at least Java 1.6 for successful compilation, which is also due to the requirements of GWT itself. The root package of the library has also changed - in the spirit of the recent rebranding of the com.extjs company, it has been replaced by com.sencha. The developers promise to release new versions of the developer preview once every few weeks, however, they note that these versions so far only demonstrate new features and the API that has not yet been fixed, and therefore are not recommended for use in development.
Links
- Ext GWT 3.0 Appearance Design
- Ext GWT 3.0 XTemplate Redesign
- Ext GWT 3.0 Developer Preview 1
- Ext GWT 3.0 Developer Preview 2
Source: https://habr.com/ru/post/124384/
All Articles