Personal opinion on software development in general, development methodologies, tools and best practices in particular

Archive for the ‘Vaadin’ Category

Vaadin: what’s new


It’s been a while since my last blog post about Vaadin. Summertime you know 😉

But Vaadin was still evolving towards an even better framework. I’ll summarize the new fancy features.

Last week I went to a very interesting talk about Android. THe programming language isn’t Java but is very similar to Java. Creating fancy applications seems still a bit difficult but one can only develop webapps of course. Vaadin also has a framework to develop smartphone applications (webapps) called Touchkit.

TouchKit

A lot of people don’t know that you can develop applications for smartphones with Vaadin TouchKit . These applications have an iPhone look and feel but will run on iPhone, iPad and Android.

TouchKit is optimized to run on smartphones so it’s optimized for low low performance and low memory (ROM) devices.

The well known Vaadin sampler, which demonstrates all Vaadin components along with the Java source code, is also available for Vaadin TouchKit: http://demo.vaadin.com/TouchKit

If you want to know more about TouchKit (who developed it, why, what’s the roadmap,…) you can read these blog posts:

Add-on directory

The add-on directory that was released this year is a marketplace where themes, UI components, tools, data components and miscellaneous add-ons are distributed to the community. Most of them are free, for some of them you’ll need to have a license.

It’s a very good initiative, no need to write a fancy component because there’s a big chance you’ll find it in the add-on directory. Most of the add-ons have a demo site, source code, project homepage, issue tracker and forum attached. But there was 1 shortcoming: maven integration.

Most Java projects are based on Maven, Spring and Hibernate and Vaadin supported all of these. But if you wanted to use an add-on in your project, you had to download the jar and add it to the classpath. Since I use Maven I do not longer like the idea of commiting jar’s in Subversion. So I added a script to SVN which contained the code to install the add-on jar in the local repository. Next I installed it on Nexus and added the dependency to the pom.xml.

But times change and the guys from Vaadin really listen to the community. They know very well that a framework on itself isn’t good enough. Integration with other common used frameworks is a must these days. So the guys set up a Maven repository, add all existing add-ons to it and all newly added add-ons will be automatically added to that repo.

More info about the add-on maven support can be found here. The code that must be added to the pom.xml file is also available on the add-on directory site.  Easy huh?

Talks

Another proove of the fact that Vaadin is still evolving are the amount of talks that cover this framework. Joonas Lehtinen, CEO of Vaadin will present on Devoxx on 17/11/2010:  http://www.devoxx.com/display/Devoxx2K10/Vaadin+-+Rich+Web+Applications+in+Java+without+Plug-ins+or+JavaScript

Another more detailed talk about Vaadin will be the success-story of the conversion of Black Belt Factory (aka Java Black Belt) to Vaadin. It’s scheduled on 30/03/2011 in Brussels and is organised by the  Brussels Java User Group (BruJUG).

The talk will take 3h and will be presented by the CEO of Black Belt Factory.

I will attend the talk, and you?

References

Advertisements

Vaadin, Maven and Spring


Vaadin is a Rapid Application Development (RAD) framework for RIA applications. I only know it for a few months but since I started experimenting with it, I’m really in favor of it.

I see a lot of advantages compared to Sun’s Java EE standard front-end framework JSF.

  • First of all Vaadin is a java library, so you only have to write Java to build a complete frontend. No need for a specific frontend language, no need for converters (for comboboxes),… This also implies that you can use the full Java power on the frontend side and that’s an huge advantage because frontend code is now type-safe and easily refactorable. You can unit test your frontend with JUnit. You can also use all existing java libraries on the frontend side, for example LOG4J.
  • Another advantage is the fact that Vaadin is easy to learn (JSF isn’t!) and to use: it’s straigtforward. It feels like developing desktop apps and for me developing desktop apps feels much more intuitive than developing web-apps the way I’m used to.
  • Vaadin uses convention over configuration. No need to register new components, validators or whatever in different xml files. Themes have a default folder and a default folder structure.
  • Vaadin is very well documented. There’s the book of Vaadin wich explains every aspect of the framework very clear. On the site there’s a blog, a FAQ section, a wiki, a forum, examples with Java source code, …
  • It’s very easy to extend. Want to create your own Validator? Just implement an interface or extend another Validator and use it. Want to create your own custom server side component? Just extend the CustomComponent class or extend from another component. There’s also an add-on directory where you can download UI components, data components, tools, themes, …

But enough about Vaadin itself. The purpose of this blog post is not to explain Vaadin itself in detail but how to integrate it with other commonly used frameworks: Maven and Spring.

Vaadin comes with a plugin for Netbeans and Eclipse. These plugins provide a wizard which makes the creation of a new Vaadin project, themes and components (also client side) very easy, it even provides a WYSIWYG editor but that’s still experimental.

But as expected (or not) the project structure created by the plugin is not the structure I want because Vaadin uses its own structure which differs from the well known Maven structure. Though this is not a big pain in the ass because Maven integration is extremely easy to accomplish. The easist way is by using Vaadin’s Maven archetype:

mvn archetype:generate
-DarchetypeGroupId=com.vaadin
-DarchetypeArtifactId=vaadin-archetype-clean
-DarchetypeVersion=LATEST
-DgroupId=your.company
-DartifactId=project-name
-Dversion=1.0
-Dpackaging=war

There are also archetypes ‘vaadin-archetype-sample‘ and ‘vaadin-archetype-widget‘. The first one generates a sample Vaadin app and the second one creates a project to illustrate how to create custom GWT widgets (yup Vaadin is based on GWT). Of course the Vaadin library itself can be found in several Maven repo’s. The only shortcoming at the moment is that the add-ons aren’t ‘Mavenized’ yet. You’ll have to download the jar’s manually. But an issue is created fror that and they’re working on it, so it will be there soon.

To enable Spring in a Vaadin app you’ll have to use SpringApplicationServlet as explained here. That’s all.

Since frontend and controller are now written in java, we can inject Spring managed beans into the Vaadin controller classes. Of course we would like to use annotations instead of all those XML config so we would like to make use of the @autowired annotation for example.

To do that we must put the <context:spring-configured /> element in our applicationcontext and enable component scanning by means of the <context:component-scan /> element to scan out controller classes.

The controller classes can be Spring managed by adding the @Component annotation but it sounds acceptable that you don’t want to make some front-end stuff Spring managed. If you don’t want to do that you can use the @Configurable annotation. It marks a class as eligible for Spring-driven configuration.

Now the last thing that needs to be done is AspectJ weaving, otherwise using the injected Services will cause NullPointerExceptions. You could add the maven-aspectj-plugin to enable compile time weaving. The disadvantage of this approach is that you have to do a Maven compile because compiling in the IDE won’t trigger AspectJ weaving.
You could change the project  into a Maven project instead in Eclipse but then everytime you save your file, Maven compilation will be executed and that’s not what we want.

We can use <context:load-time-weaver /> to enable AspectJ load time weaving. This way we don’t have to run a Maven compile to weave. You’ll have to pass spring-agent.jar to the application when running it to make loadtime weaving work. Once this is done, it’s pure AspectJ LTW which can be configured using ‘META-INF/aop.xml’ which is automatically loaded as AspectJ LTW is initialized by <context:load-time-weaver/>. The last step is to pass ‘-javaagent:path/to/aspectjweaver.jar’ to Tomcat’s VM arguments instead of using the aop.xml and load-time-weaver tag.

If you don’t like load time weaving (it makes hot redeployment fail from time to time), you can remove the <context:load-time-weaver> element and the aop.xml file. Instead you can install AJDT plugin for Eclipse. The project will be recognized as an AspectJ project and yhe only thing you need to do is adding spring-agent.jar to the project’s Inpath.

More Vaadin stuff in one of the next blog posts!