For the past few months I have been involved on a project with
a client that involves updating a customer portal. The first steps of the
project were to conduct POCs to determine what frameworks and technologies we
would use to update the portal. As a team we chose to use Liferay as a portal
framework and decided to use Vaadin as out application development framework. For
the past two weeks I have been working with Vaadin consistently to create some
of the core functionality in the portal. Our team even went through a three day
training session to learn Vaadin’s capabilities, patterns and best practices.
Our team chose Vaadin over other web application frameworks
because of its ease of use, versatility, and its cross-browser consistency.
Aside from these key factors there were also some larger project based
variables that seemed to align well with Vaadin’s target market as expressed in
Hildeberto’s
overview.
Vaadin is built off of Google’s Web Toolkit (GWT) so it is
backed by a strong core and provides a variety of popular features for building
web apps. In addition to building web apps we will also be using Vaadin to
create portlets within Liferay. One of the nice things about Vaadin is that it is
all Java based, similar to the Java Swing framework, there is no explicit JavaScript
or html required to create a fully functional portlet or application.
Vaadin 7 was
recently just released in April 2013 and would be a good baseline for
development, however due to restrictions with browser support our team will be
using Vaadin 6 in our environment. The “deal breaker” for not using Vaadin 7 is
its compatibility with outdated version of Internet Explorer. Vaadin 7 only
supports IE 8+ browsers, where Vaadin 6
supports IE 6+ browsers. A large percent of the projects current portal user
base still uses IE 7 (and a much smaller but still accountable percent use IE
6).
Currently, most of my development with Vaadin has consisted
of displaying table contents. The portal allows the client to display needed
information to its customers, and the most intuitive way of doing this is
through a tabled view. My role has involved working on an advanced table view
which offers the customers an extensive list of options for viewing information
within the table. The list of features I have been working on incorporating for
the project consists of a:
- General search – Searches all columns for the search criteria.
- Advanced search –Lets the user search for criteria within a specific column.
- Collapsible columns – Columns can be shown or hidden from the table.
- Reordered columns – Columns can be reordered throughout the table by drag and dropping them into the desired order.
- Sorted Columns – The contents can be sorted in ascending or descending order by column when clicking on the header.
- Table Export – The contents that are displayed in the table can be exported to excel, pdf and/or xml.
- Print – The contents that are displayed can be printed in a user friendly table.
Naturally, the majority of these features are supported in
Vaadin’s API making them very easy to implement. If they were not we may have needed
to reevaluate our framework choice. However,
a few of the features are supported as Vaadin
add-ons which are side projects created by individuals and shared with the
community. The add-ons have been very helpful however for implementing desired
functionality quickly. However, I have come across a problem where some of
these features are not compatible with other available features. For example the advanced search (filter table)
and the excel export will not work together without some modifications. Our
team will have to look into how we can incorporate these features together to
give the customer the greatest benefit of using our advanced table’s
functionality.
One concern about Vaadin that a colleague brought to my
attention is that Vaadin is very concentrated framework and if there is functionality
that you want to create that is outside that scope of what Vaadin has to offer
it might be very difficult to implement and take much more time than it would
with a JSF framework. In training we were taught about how to create widgets
and custom functionality for Vaadin using the GWT. I am currently working on
some customizations to that Vaadin table that may fall under this category as
the functionality I am trying to customize is not functional and would include
modifications to how Vaadin’s components work. If all goes well the customizations
will be quick and painless, and if not… you may be hearing from me again. A
framework that limits a developer’s freedom to customize is not one to be
highly praised.
All in all I have really enjoyed working with Vaadin. It has
provided a vast variety of functionality quickly and consistently across
browsers. After the training session it became apparent as to how to utilize Vaadin
in our portal project to take advantage of all the features it can provide on
both the client and server side. I have been really happy with the integration of
Liferay and Vaadin having no issues with the two frameworks working together.
Vaadin’s API has provided a majority of the functionality required for the
project and it will be interesting to see how easily customizations to Vaadin’s
components can be applied. If anyone has any experience with Vaadin or is interested
in learning what patterns our team has used feel to leave a
message.
