porotype }> @porotype - Tumblr Blog

Sharing Vaadin applications on Facebook

Have you ever wondered where the little ‘preview’ thumbnail comes from when you share links on Facebook (and G+), and how you might go about customising that for your Vaadin application? Read on!

#vaadin #facebook #g+#share #application #open graph

V-everything - important note about naming stuff in Vaadin

There seems to be a lot of misconceptions about naming conventions in Vaadin applications and add-ons, so I thought I'd better attempt to clear things up right away.

I'll make sure the following is stated clearly in the upcoming Vaadin 7 tutorials and such, but it applies to v6 too, and is IMHO an important enough point to bring it up right away.

There is a convention that some things (css classnames, client side widgets) in Vaadin are prefixed with the letter "v". This convention is apparently often copied into add-ons and projects using Vaadin, but:

Please do not prefix your things with "v", it is a scoping prefix intended for the Vaadin core.

#vaadin #naming #css #stylename #prefix

OAuth with Vaadin - Login with Facebook/Twitter/..

Easy user registration and login still seems to be somewhat of a uncracked nut. Not because we're not trying, but it's actually a pretty hard nut to crack - at least in a way that pleases both developers and users. For example, while OpenID first seemed like a pretty good idea, it seems it's just too weird and complicated for the regular user, and recently several fairly prominent sites have abandoned it.

The new favourite seems to be OAuth, popping up pretty much everywhere in the form of "Log in with X" -buttons. The reason is obvious: it's dead simple and fast for the users to use and understand - and that includes both registration and login. You just "Log in with Facebook", and you're done. OAuth is also quite easy to implement in your application, especially using some of the libraries available.

In this post, I'll present a simple solution for providing such login functionality in Vaadin applications (note that this is just one side of the coin - other OAuth scenarios are not presented).

#vaadin #add-on #oauth #login #facebook #twitter #linkedin

Compressing all the Vaadin things

It's usually a good idea to gzip compress all the plaintext http traffic in @Vaadin for speed and in order to minimize the amount of transferred data. This is another server-specific configuration, and is again applicable generally and not just for Vaadin.

UPDATE: Click on images for hi-res in new window.

What?

When gzip compression is enabled, the server will compress the data sent to the browser, often resulting in quite dramatic reduction of the size of the transferred data thus download time. Compression is used for plain-text content, which can typically be compressed quite efficiently (achieved compression ratio vs. increase in CPU load) with the gzip algorithm. If you don't have a very specific reason not to do so, it's usually a good idea to let the server handle this (as opposed to rolling your own implementation), since it will be optimized for this use-case.

The decision whether to compress is actually depends on a number of things: first the browser tells the server whether or not it supports compression using the Accept-Encoding http header, and if the server also has compression support turned on it will check the mime-type of the content, and potentially the length, before deciding whether or not to compress. If the content is compressed, the server will add a Content-Encoding http header to inform the browser of this fact. You can get more details about this form Wikipedia.

When?

We obviously don't want to (try to) compress stuff that is already very well compressed, such as jpeg files, so the server needs to know which mime-types we want to compress. Usually the server comes preconfigured to compress some well-known types, such as HTML and CSS, but one mime-type that is usually missing is the one used for the JSON communication that Vaadin uses - namely application/json.

Servers also usually support configuring a minimum content-length for compression, since compression does not work very well for very short content. In the Vaadin JSON case however, the content-length is not known at the time the headers are sent, so it's all or nothing - the minimum content length can not be checked. This is not usually a problem, though - Google recommends a limit between 150-1000 bytes, which is easily exceeded by most Vaadin JSON messages. If you have lots of very small messages (maybe some sort of polling/push) you might want to check this though.

How?

This is again a server specific configuration issue; please also read your server's documentation for details. The general method is to make sure compression is enabled (it usually is), and that it's enabled for all the appropriate mime-types (something might be missing). We'll take a quick look at the usual suspects, Tomcat and Jetty.

Tomcat

In Tomcat, you should configure your connector to have compression="on" and compressableMimeType set to the appropriate mime-types (the default in Tomcat 7 is "text/html,text/xml,text/plain", which indeed is missing application/json). Additionally, you can tune the compressionMinSize to match Googles recommendations. You can do this in the server.xml:

The documentation can be found here: http://tomcat.apache.org/tomcat-7.0-doc/config/http.html

Jetty

In Jetty, you have to enable and configure the GzipFilter for your application. You can do this by adding a filter definition to your web.xml:

<filter> <filter-name>GzipFilter</filter-name> <filter-class>org.eclipse.jetty.servlets.GzipFilter</filter-class> <init-param> <param-name>mimeTypes</param-name> <param-value>text/html,text/xml,text/plain,application/javascript,application/json</param-value> </init-param> </filter> <filter-mapping> <filter-name>GzipFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping>

Note that you could actually apply the filter to just Vaadin JSON requests (*/UIDL), but then no other content would be compressed.

Also, with Jetty you can pre-compress static files (index.html -> index.html.gz) and easily have Jetty serve those instead. Refer to the documentation for details: http://docs.codehaus.org/display/JETTY/GZIP+Compression

Testing

Ok, so now you know in theory how to enable gzip compression for Vaadin in Tomcat and Jetty. But in practice you'll want to make sure that all the appropriate mime-types are compressed, and verify that it's actually working and making a difference. You can use the Development Tools in Chrome, or Firebug in Firefox to do that - let's take a look:

Here is how a compressed response looks (in Chrome):

And here is a response without compression (in Chrome):

Here is the same request, compressed and uncompressed (in Firefox):

I suggest you try it out to learn how to spot the difference: fire up a project in Eclipse, and have a look in Chrome/Firebug - chances are you don't have any compression enabled. Then try modifying server.xml and see how it affects the responses.

As always, feedback is welcome! Errors, comments, more details needed - let me know!

#vaadin #performance #gzip #compression #json #uidl

Spotify + Vaadin = truthy

For the last workday of the year, I decided to spend my @Vaadin #CF on something a bit different: @Spotify + @Vaadin

Spotify recently announced the Spotify Apps API, and I conveniently gained access today. This being the last workday of the year, I decided to spend some CF time (the Vaadineer version of Googles 20% time) checking if it's possible to use Vaadin to make Spotify Apps.

The environment provided is basically Chromium, and you can grant your app remote XHR access to specific sites - in short, it lookes pretty promising! And indeed, I was able to run a Vaadin application quite easily.

However, before you get your hopes up, I found this notice in the documentataion:

In order for Spotify to be able to verify the security aspects of the submitted applications, the JavaScript code must not be minified or obfuscated.

Uh-oh. Vaadin is using GWT, and GWT javascript is indeed quite obfuscated. I guess you could compile using pretty or detailed modes, but I'm not sure that would be sufficient. I guess I'll have to contact Spotify and ask...

Anyway, if you still want to give it a shot, here's the basic procedure.

Spotifyifying a Vaadin application

First get a version of Spotify that supports Apps (then apply for Apps developer status, so you get the devel tools in Spotify).

Then make a Spotify folder (~/Spotify on Mac, My Documents/Spotify on Win) and a folder for you app under that (e.g ~Spotify/vaadin/).

Now choose a Vaadin Application you want to spotifyify. Any test application will do for now. Browse to it (make sure it works) and copy the content of the page into ~Spotify/vaadin/index.html.

Next, create a manifest.json in the same folder with the following content:

{ "BundleType": "Application", "AppIcon": { "18x18": "vaadin.png" }, "AppName": { "en": "Vaadin" }, "SupportedLanguages": [ "en" ], "RequiredPermissions": [ "http://192.168.11.18:8080" ] }

Replace stuff to your liking - especially make sure the RequiredPermissons points to your application. Mine is running at http://192.168.11.18:8080.

Now copy the whole VAADIN folder from your Vaadin application to e.g ~Spotify/vaadin/VAADIN/ - yes, we can actually install the widgetset and themes locally, and only make UIDL requests to the server. Neat.

In order for the application to know where the server is located, we'll need to edit index.html just a little bit: look for the part that says appUri:'...' and make it point to your server. Mine looks like this:

appUri:'http://192.168.11.18:8080/'

That is basically it! Fire up Spotify, and search for spotify:app:vaadin where the last part is the name of your app (vaadin in my case).

Now what?

The main problem with this is that it's quite unclear if apps like this would be allowed into Spotify. I'm guessing the answer is a firm 'no' unless you compile pretty/detailed, and perhaps not even then. This is something Spotify needs to comment on - I'll get back to you if I find out the answer! :-) Until then, this will remain an interesting experiment.

Ignoring the possible problems with app submission, the obvious next steps would be:

Actual API integration. Vaadin add-on + GWT library.

Customized theme based on the css themes Spotify provide.

Anyway, have a nice new years eve, and let me know if you have some thoughts on this topic!

#vaadin #spotify #api #labs #experiment

Serving static content with Vaadin

I’ve heard the question “how do I serve static resources with Vaadin” (and it’s relatives) quite many times, so I thought it’s time to address this subject.

This is actually not so much a Vaadin specific issue, but mostly a generic servlet issue - but there are some Vaadin specific things you should know.

Also, Vaadin applications are quite often mapped to “/*”, which requires you to know how to configure your setup correctly to use the ‘default’ servlet for static content - I think this is the main reason Vaadin developers seem to struggle with this.

Let’s start:

Using the default servlet

Quite often you have your Vaadin application (or any servlet for that matter) set up to handle all paths ‘below’ its context:

<servlet> <servlet-name>MyApp</servlet-name> ... </servlet> <servlet-mapping> <servlet-name>MyApp</servlet-name> <url-pattern>/*</url-pattern> </servlet-mapping>

The application will now handle http://…/, http://…/asd as well as http://…/asd/foo and so on.

But wait! You have some static files you want to serve - perhaps an image, or a html help file. You create a folder named ‘static’ and put the files there, but http://…/static/help.html just renders the servlet, because it’s handling all the things. Default servlet to the rescue:

<servlet-mapping> <servlet-name>default</servlet-name> <url-pattern>/static/*</url-pattern> </servlet-mapping>

This tells your servlet container to use the ‘default’ servlet for anything under the ‘static’ path (I tested with Tomcat and Jetty - YMMV if you are using something else). The default servlet is a built-in servlet that is made for serving static files (note that you are still serving files trough a servlet - more on that later).

Serving VAADIN

Vaadin applications use some static resources, such as widgetsets (GWT javascript files) and themes (css and image files). These are loaded from paths starting with ‘VAADIN’, as you can see with e.g Firebug. For convenience these file are by default packaged into the vaadin.jar and served from it trough the Vaadin servlet, but this is not the most efficient way, and it’s recommended that you deploy the static resources separately in production environments.

Let’s start by using the ‘default’ servlet to serve static Vaadin resources: first extract the ‘VAADIN’ folder from the vaadin.jar to the root of your web application (a jar is a regular zip file - use unzip or any application that can handle zips):

marc$ pwd /Users/marc/Projects/Staticfiles/WebContent marc$ unzip WEB-INF/lib/vaadin-6.7.1.jar `unzip -Z -1 WEB-INF/lib/vaadin-6.7.1.jar | grep VAADIN/`

Then add this after your application’s mapping in web.xml:

<servlet-mapping> <servlet-name>default</servlet-name> <url-pattern>/VAADIN/*</url-pattern> </servlet-mapping>

NOTE If you update the vaadin.jar, you have to remember to update the VAADIN folder (by re-extracting from the new jar), since the files in the jar might have changed. This is one of the reasons it’s convenient to serve the files directly from the jar while developing the application.

However, we’re still serving the static files trough a servlet, which is usually not the most efficient way (note that different servlet containers perform differently in this regard). Let’s look at how that can be fixed.

Going for performance

Serving static files trough the servlet containers default servlet is usually not seen as the most efficient way to serve static files. Instead, there are servers that are particularly good at serving static content, so for production environments it might make sense to have a setup where the static content is served by such a server, while the application requests are passed trough to the servlet container.

Note that servers evolve, and you might be able to get sufficient performance for your use-case without using separate file servers and get away with a simpler setup.

Also, I am not going to show you how to configure any particular server for performance, since this might vary depending on your setup. Instead, I’ll just show the basic idea, and point in (hopefully) the right direction.

YMMV, please test it yourself :-)

Apache httpd

A common setup is to have an Apache server in front of the servlet container. AJP currently seems to be the prefered way to do this with Tomcat, while mod_proxy is strongly recommended for Jetty.

Nginx

Another setup that is very popular at the moment to use Nginx to serve static files. Setup Nginx to listen to port 80 (or whichever port your application should run on), tomcat/jetty on 8080, and do something like this in your nginx.conf:

location / { #servlet proxy_pass http://127.0.0.1:8080/; } location ~ .*/VAADIN/.* { root <FILESYSTEM_PATH_TO_STATIC_CONTENT>; index index.html index.htm; }

Note that this is a quick example - you should familiarize yourself with Nginx configuration and set it up to suit your needs. You might want to look at the JavaServers example.

CDNS

Finally, you might want to consider deploying your static files on a CDNS instead of serving the content yourself.

Summary

When making a production deployment, please make sure that static resources are extracted from the vaadin.jar and served using a method that matches your performance requirements (‘default’ servlet, Apache httpd, Nginx, CDNS, …) Verify that your requirements are met by testing and measuring!

Also make sure that the cache headers are set appropriately for the static content, and that gzip compression is enabled - also for JSON responses (unless you have specific reasons for not doing so).

Finally, if you want me to elaborate on any of this, please let me know!

#resources #static #vaadin #performance

Trending Blogs

Recently Viewed Blogs

porotype }>