«Back
Empowering Software Developers with Vaadin 7

A couple of weeks ago, I posted the roadmap for Vaadin. Only the timeline was laid out – not the what we are actually doing. After a lot of planning, we have come up with a list of things we want to have – and believe we could fit – in Vaadin 7. The list is sorted by the preferred implementation order – not in the order of importance. We want to start from the things that need the most feedback from you. This should give us more time to sort out any design problems the community points out before the release.

While the list of what we'll do is a long one, it can be simply summarized to the three major things we want to achieve in Vaadin 7:
  • Give more power and freedom to developers.
  • Make extending and plugging Vaadin simpler.
  • Clean up where it smells.

 

1. Empower Developers

Vaadin has an exceptional model of providing three layers of abstraction for the web user interface development:
  1. Server-side user interface development with any JVM compatible language,
  2. Java-based client-side development model provided by GWT, and
  3. full power of HTML5 by developing in JavaScript.
Hiding the lower abstraction levels is a powerful way of keeping things simple.
 
Sometimes you want to go through the abstractions to get more control on the finer details. This is supported in Vaadin 6, but often could be easier. Sometimes it feels like we would be trying to argue "you do not want to do it, it is the wrong way to do it, it should not be too easy – just to keep you safe". We should not.
 
With Vaadin 7, we try to remove abstractions where they really do not add value, and try to better support you when you want to go through the abstractions, but are also careful not to loose any of the "wow this is easy" magic we have built into Vaadin 6.
 
Some of the things we'll do:
  • Split the "browser window" API into a lower- and a higher-level API that
    • Give full control over how windows are managed,
    • Give easy access to HttpServletRequest and PortlerRequest, and
    • Provide a much simpler built-in API for view management.
  • Move layout calculations back to the browser in order to
    • Improve rendering performance (a lot), and
    • Allow full control of the look and feel in CSS themes, including borders, margins and paddings.
  • Use theme selectors on a per-component basis to allow you to easily override themes for any given component – or possibly even mix themes.
  • Let you inject pieces of CSS on the server side for simple dynamic changes to components.
  • Allow declaring Javascript callbacks on the server side to let you more easily integrate Vaadin to other JavaScript components on the web-page.
  • Ease the embedding of Vaadin in JSPs with a special tag lib that makes it trivial to start adding small Vaadin-based parts to existing JSP and JSF applications.
  • Give you centralized control of CSS and JS loading to ease the use of existing JavaScript libraries.
  • Provide a built-in API for on-the-fly translations of all texts and resources in UI components.

 

2. Embrace Extendability

Probably the best decisions we have done in Vaadin 6 was to make creating, packaging and distributing add-ons really easy. Because of this and especially thanks to you, there are now 213 add-on components for Vaadin in the directory. We were so exited about this that we even started to release additions to the core framework as add-ons in the directory before integrating them in the framework.
 
We want to take this even further. We want to open up more and clearer extension points, and make it even simpler for you to build and distribute components and features on top of the Vaadin framework.
 
Some of the planned things:
  • Create two new communication APIs for connecting the client- and server-side of your UI components:
    • A clean remote procedure call (RPC) API,
    • a shared-state API to let the framework handle state sharing for you, and
    • possibly clean up the current "variable"-based communications.
  • Alleviate language limitations for multiple inheritance: We'll add a plugin API for easily adding features to the Application servlet without extending it.
  • Add a new plugin type will to make it easy to develop add-ons that are not widgets but still need to plug into a client-side widget set.
  • Provide a generic component to port and package JavaScript widgets to Vaadin without requiring GWT compilation.
  • Provide a generic decorator interface to plug new features into any user interface and distribute these features as add-ons. Think of client-side validations and floating info bubbles.
  • Make creation of component containers easier by removing unnecessary features from the interface.
  • Add a mechanism to package CSS and images with server-side add-ons to ease creation of server-side composition-based add-on components.
  • Create a plug-in API for server-push add-ons, plus a push add-on that provides support for web sockets.

 

3. Clean Up

During the previous 10 years when we have been building this framework, we have left some garbage lying around and some rooms in the house are in need of some new paint. Parts of the API still are over-generic and confusing, because in 2002 we wanted to support other terminals in addition to web. The web won and now there is no need to overgeneralize any more.
 
With Vaadin 7, we are going to clean up the parts of the API we are not proud of anymore.
 
Some of the renovations planned:
  • Re-design forms to make it a lot simpler to build more powerful forms.
  • Clearly separate "sub-windows" by renaming the "browser-level window" to "Root"
  • Remove unnecessary abstractions built around the Application class to simplify learning and give more control.
  • Replace integer constants with enums, remove the unnecessary Container.Ordered interface and remove already deprecated APIs.
  • On the client side, review the APIs to better support decoupling of widgets from the server-side communications. This would make it possible to
    • do client-side compositions out of Vaadin widgets,
    • use GWT Designer to design client-side compositions, and
    • easily move parts of the UI logic to the client side.
  • Improve session management:
    • Never see those red error messages again.
    • Keep sessions open while the browser is open by default.
    • Default to one server-side "Root" per one page to make applications more "web-like"
  • Provide seamless support for running more than one Vaadin application per web page.
  • Add built-in support for HTML sanitation to make it easier to build secure applications.
  • Provide better support for accessibility standards – more specifically, WAI-ARIA.

 

Compatibility

We have been very happy how Vaadin 6 has turned out and how we've been able to iteratively add features and build on it while keeping it backwards compatible. In fact, for the most parts, Vaadin 6 is backwards compatible back to (Millstone) version 3 – released way back in the end of the year 2002.
 
Major releases are not guaranteed to maintain backwards compatibility. With Vaadin 7, we would like to take the opportunity of cleaning up and making the release better for everyone – even if this would mean less backwards compatibility. The guidelines for us are the questions:
  • How much work it would be take to port your application from Vaadin 6 to Vaadin 7?
  • Can we write clear guidelines for upgrading?
 
We want to keep the pain of moving from 6 to 7 minimal but at the same time be able to make Vaadin cleaner, simpler and better. For some features we will provide cleanly separated backwards compatibility support APIs – possibly as add-ons – to ease the transition.
 
One major change is that we will be dropping support for Internet Explorer versions 6 and 7. Without these ancient and somewhat broken browsers, we are able to make the code much cleaner and move layout calculations back to the browser. If you really have to support these browsers, you have two options:
  1. Use Vaadin 6 (it will be supported until the year 2014), or
  2. Get your users to install the Chrome Frame plugin.

 

Details

A detailed list of all changes is available at the Vaadin 7 wiki.   Furthermore, our design process is open and design documents will be maintained there while we are planning and experimenting.
 
Please give us comments on the forum:
  • What do you think of the plan as a whole?
  • Have we omitted something crucial?
  • Is our design flawed?
 
And please test the results as soon as we get the first alpha release out – by the end of the year.
Comments
Trackback URL:

I agree cleaning, I agree the continuous way to simplicity above all, but I do not forget other good things
Well done and applause ...

Posted on 11/3/11 4:47 PM.

Top
Amazing lists of upcoming improvements, most of them being adressed are the ones that would greatly ease our development process and let us develop powerful web apps

Thanks VAADIN !!!!!

Posted on 11/17/11 11:57 AM.

Top
VAADIN is simply wonderful. Ten years of quality work by the IT Mill team. Congratulations!

A couple of features can be considered (not sure if this is the right place):

1> Better mechanism for Load testing of VAADIN applications.
2> Simple mechanism for monitoring session size. Without having to depend on external APIs or workarounds. Something that is intrinsic to the VAADIN toolkit.

All in all, thank you.

Posted on 12/7/11 3:34 AM.

Top
Concurrency and distributed systems are probably among the hardest parts of software engineering. Basic Java EE apps usually don’t need to deal with these issues that much, but increasing
We're pleased to announce the public release of Tori – the modern and sleek discussion forum for Liferay portal . We've kept Tori under the blanket while developing it and
There is a point in every enterprise web application project when the scalability of the application under development is wanted to be measured. There are several reasons for why scalability tests
Vaadin TestBench is a browser automation tool, suited for creating UI level tests for Vaadin applications. It is based on Selenium 2, which means that all features of Selenium 2/WebDriver are also
Servlet 3.0 is awesome, so is CDI . They work well and are a joy to set up. Even adding the Vaadin Navigator to the mix isn’t an issue, since you can use the CDIViewProvider to maintain the
Showing 1 - 5 of 100 results.
of 20

See all blog entries
Subscribe to this blog