Page tree
Skip to end of metadata
Go to start of metadata

Rationale

Vaadin 7 is in just the right state to start using it: even though the release candidate is not there yet - it is very close. At least all the API's are stable now, so Vaadin-related code can be ported once and forever.

Benefits

So what does the new version of the framework bring to Magnolia 5?

Application is Now Replaced with UI Class

@Theme("admincentraltheme")

@PreserveOnRefresh

public class AdminCentralUI extends UI {

...

}

@PreserveOnRefresh - instructs that after refresh the old server-side state is used, if it is omitted - a ?restartApplication effect would be applied.

Solution for Multiple Browser Tab Support

Every new request to the server gets a new session and UI instance. Having the application open in separate tabs or windows means that the instances are totally separate from each others, and thus won't conflict and cause any out of sync or similar issues. Which means we can drop the existing custom solution for Vaadin 6.

Architecture improvements (client side)

Currently the client-side implementation of components and layouts is based on the MVP pattern wherever appropriate. Vaadin 7 supports and even forces the developer to use a similar concept. What used to be Vaadin client-side classes (e.g. VPageEditor) is now called a Connector (e.g. PageEditorConnector). Connector is responsible for creating the view, coordinating hierarchy changes, view size management and various events. With a reasonable effort it is possible to convert Paintables and Containers to connectors. At the same time - the view more or less stays the same and can be reused. 

Component server-side restructure

Some essential components like CustomField were integrated in the core. Finally, there is a possibility to define components that can have children but not layouts by nature (like MagnoliaShell for instance). Single-component containers appear to be handy as well (for tab-sheet tabs and dialogs for example).

Improved Client <-> Server Communication

Currently used communication mechanisms of paintContent() / updateFromUidl() and Widget RPC are not typesafe, have fairly limited set of types supported for communication and sometimes very hard to control. Now we can use the concepts of SharedState and RPC

SharedState contains all the persistent properties of a component that must be maintained between browser refreshes. State is created by the connector and in the same fashion can be used both on the client and the server sides. Communication through the shared state works in one direction: it is only possible to send changes from server to client.

An RPC mechanism can be used to communicate from the server to the client. In effect, the server-side component can call methods that are executed by the client-side connector. As opposed to shared state, no information is automatically re-transmitted when the client-side state is lost (e.g when a browser reload is invoked).

Whether shared state or RPC is appropriate depends on the nature of the data being transmitted, but if the information transmitted needs to be retained on the client over a page refresh, you should probably use shared state. You'll probably find shared state more appropriate in most cases, and server-client RPC extremely useful in a few cases.

Automated Serialization

Among primitive and basic types RPC and shared state support simple POJO's with fields of either mentioned types or Connectors (which are automatically treated as Components on the server side). This means that we no longer have to rely on GSON for sending the objects to the client side and can drop the JavaScriptObject counterpart classes. A good application of the feature was found in MagnoliaShell for instance: we no longer have to transfer the fragment Strings, but rather a Fragment object that encapsulates all the handy operations instead (in turn it could be merged with Location if corresponding decision will be made).

Significantly Lighter Layouts

Due to border-box model that is applied to elements in Vaadin 7 it is a lot easier to support margins, borders and paddings and as a consequence - to drop a certain amount of helper DIVs. E.g. CssLayout is now just one DIV element, ordered layouts (Horizontal and Vertical) have minimal overhead (one DIV for a slot per component). Components that have complex client-side structure are easier to maintain now as there are hooks for the most important phases of the widget lifecycle: initialization, hierarchy change, state change, un-registration which allows us for building more readable and robust code.

Better Size Calculation Management

While Vaadin 6 translates all kinds of size-values to pixels, Vaadin 7 simply uses inline styles delegating size management to the browser. What is more, now it is not a responsibility of the parent widget to layout its children, it itself adapts itself if needed, so complex hierarchies of custom components are now easier to maintain. Also the presence of response-handler locks looks promising for transitions support.

Performance Concerns

Let us face it - the new communication mechanism in spite of it wonderful features is not yet fully optimized. Thus, some components lose the communication benchmarking against V6 versions: the amount of JSON transmitted is bigger and time it takes to parse is longer. However, there are several points to be cleared here. First of all, the research is done mostly against basic Vaadin components, not all of which were ported to the new version of the framework and currently function through legacy interfaces workaround. It can be expected that in the near future (winter/spring 2013) situation will improve in that sense. Most of Magnolia crafted widgets already use Vaadin7 approach. Another promising point that performance of RC1 is already way better than in preceding beta11 (according to some research - +20%). Anyway, Magnolia team should use the new communication API responsibly. For instance, transferring big POJOs is probably a bad idea as long as client-side doesn't need to know every single property passed on.

JavaScript

Now it is possible to use JavaScript libraries and widgets without even JSNI (of course with restrictions, but nevertheless). A good example could be the info.magnolia.ui.vaadin.editor.JCrop class that extends Vaadin Image component in order to apply JCrop to it.

DataBinding Changes

  • Generic properties - now com.vaadin.data.util.Property is parametrized with its value type, which allow for easier development of the fields. On the other hand, most of the DataBinding API in Vaadin stays untouched meaning that developing and working with containers would produce warnings abut raw types and unsafe casts sometimes (get/set propertyDataSource is a good example).
  • Transactional properties - now it is possible to organise fully functional two-phase commit process (such properties track previous values allowing to rollback).
  • Improvements of Form management - a FieldGroup class that could possibly act as a context helper for the forms and dialogs.
  • Converter - interface used for conversion between the datasource (JCR property and a Vaadin component).

SASS

It is now fully possible to use Sass for theming while the current stylesheets work just fine.

  • No labels