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.
- Give more power and freedom to developers.
- Make extending and plugging Vaadin simpler.
- Clean up where it smells.
1. Empower Developers
- Server-side user interface development with any JVM compatible language,
- Java-based client-side development model provided by GWT, and
- 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.
- 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.
- Provide a built-in API for on-the-fly translations of all texts and resources in UI components.
2. Embrace Extendability
- 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 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
- 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.Orderedinterface 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.
- How much work it would be take to port your application from Vaadin 6 to Vaadin 7?
- Can we write clear guidelines for upgrading?
- Use Vaadin 6 (it will be supported until the year 2014), or
- Get your users to install the Chrome Frame plugin.
- What do you think of the plan as a whole?
- Have we omitted something crucial?
- Is our design flawed?