viernes, noviembre 25, 2011

Your big daddy's got no place to stay, Bad communication, I feel like the president of the USA (Mr. Bad Guy - Freddie Mercury)

In current post I am going to explain how to implement nice web form using HTML 5 and CSS 3 effects, and how can be integrated into Spring MVC web application.

First thing to do is create a Spring MVC skeleton project using STS Spring Templates. In fact you can use any other method but I prefer to use a standard template.

Next step is create an HTML 5 web structure, but exists some online applications that can do this for you, hence I am going to HTML 5 Boilerplate site, and create a custom HTML 5 template.

Then open downloaded zip and copy required structure into previous generated project. Css and Js folders into resources directory, and rename index.html to index.jsp and copy it to views directory.

Now open servlet-context and add mvc:resources tag for serving static resources.

If you deploy application a white screen should be showed but without any client/server error.

Let's start creating next html form.

Now open index.jsp and remove div with id main and create next form:

And now if you run again, you should see something like:

Add @import url(; on top of CSS file.This will make a nice font available from Google Fonts directory.

Now it is time to start applying CSS for creating a better layout. Open style.css and modify/create next elements:

And now your form should look with next layout:

See that new font is not used, simply find body,button,input,select,textarea entry and remove font-family property.

Better than before, see how only modifying CSS, form layout is modified.

And now let's start with CSS3 magic.

First trick is adding shadows and gradients to form.

And next lines into input, textarea style:

where -moz prefix is used for Gecko based browsers, and -webkit is used for Webkit browsers.

Next lines add some mouse over effects into form elements.

And to finish applying styles, we are going to modify submit button.

Remove input[type="submit"] from button and input style.

And add next lines into CSS file:

CSS magic is over, now it is time to start with server side.

If you look careful Spring taglibs, you will see that you cannot create for example email input types directly or URL types to cite a few. So I decided to use a new template engine called Thymeleaf, that offers a really nice approach for integrating HTML 5 with Spring MVC applications.

The main goal of Thymeleaf is to provide an elegant and well-formed way of creating HTML 5 templates. Its Standard and SpringStandard dialects allow you to create powerful natural templates, that can be correctly displayed by browsers and therefore work also as static prototypes. This is possible due the absence of taglibs like  <%@ taglib prefix="form" uri="" %>.

First thing to do is change index.jsp to index.html, and change ViewResolver to Thymeleaf ViewResolver:

First add Thymeleaf dependencies into pom and then modify servlet-context.xml to register TempateResolver, TemplateEngine and ThymeleafViewResolver and remove the deault view resolver.

Next step is modeling our form to a model class, and modify Spring Controller to manage form submition.

Model class is not shown because is a simple POJO with form fields. Let's see how controller is modified.

Open HomeController class and create two methods (GET, POST) to deal with HTML5 form. Note that it is a typical Spring Form Controller;

And finally we are going to templarize index.html content, using Thymeleaf engine.

Open index.html and make next changes:

Add Thymeleaf namespace on html tag.

<html xmlns:th="">

Then change form tag with two new attributes, one with object's model name (form backing object) and other one with submition URL.

<form action="#" th:object="${messageInfo}" th:action="@{/}" method="post">

Next thing to do is change each form element with th:value attribute containing backing object property name.

<input type="text" name="name" value="" id="name" placeholder="Your Name" required="required" autofocus="autofocus" th:value="*{name}"/>

And more few changes should be performed:

Use DOCTYPE instead of doctype

At time of writing this post, html5boilporate introduces link tag without closing, so Thymeleaf parser will throw an exception if is executed as is, so let's terminate link tag and meta tags.

And finally last change is required because of xhtml correctness:

<script> tag is surrounded with CDATA tags. See explanation here:

Now you can deploy application and your HTML5+CSS3 form is displayed and data submitted is displayed through server console and form page is reloaded with introduced data. And now I am going to explain what are those strange expressions in form and then we will add a new page.

Inside each Thymelef attribute four kind of expressions can be used:

  • ${...} are Spring EL expressions and are executed on model attributes.
  • *{...} are expressions executed on the form backing bean, it is like a pointer to form object (root).
  •  #{...} are for internationalization.
  • @{...} are link expressions to rewrite URLs.

And before jumping to next section try this, instead of opening index.html from http://localhost:..... try to open from your drive file://.... and I suppose you see that that's not a nice prototype because no styling is applied. This happens because we are using CSS location as:

<link rel="stylesheet" href="css/style.css"/>

HTML file is at /src/main/webapp/WEB-INF/views/ and this directory does not contain css folder. And now you can think that I have not told you the true about prototyping with Thymeleaf, but wait trust me and change that line to:

<link rel="stylesheet" href="../../css/style.css" th:href="@{/css/style.css}"/>

And open again, and wow now you can see it, a real page as one generated by the server. What we have changed is that when a browser opens HTML file without using template engine (offline), href attribute is used, but when page is online (and requested file acts as a template), th:href attribute is used.

Listing Messages:

Let's start creating a new HTML file to display all inserted messages and apply some styling with CSS.

First add a new CSS property to apply same design in table.

New CSS 3 property (nth-child) is used so even tr tags of a table will contain different style than odd tr tags.

Then create a file called list.html in same level of index.html:

This is a copy paste of index.html but changing div with id content.

In this case we are using another nice feature of Thymeleaf, collection iteration. With th:each you are iterating over a collection of elements. See that rowStat variable can be used for retrieving column information like number of column. And also see how we are defining default values between td tags, so this file is a prototype too.

Next step is changing our controller, so homeForm (renamed to showResults) method returns a list of messages:

Using a simple list as repository is not a good design, but for teaching purpose is enough. See that view name is set to list, and list of messageForm are sent back with model name used in th:each attribute.


Next step is internationalizing the application. For this reason we create a message properties file ( into src/main/resources/locale:

Then you must configure Locale beans in Spring context file.

And finally change index.html and list.html static values to internationalized keys using #{} expression:

<th th:text="#{theader.count}"></th>
<label for="name" th:text="#{}">Name: </label>

And although internationalization is used, web page is still a prototype.

It seems like application is working well, but it has one problem. Try next sequence of events:

1. Add a new message.
2. When list of all messages are shown, refresh the page (F5).

And surprise the same message is added too, so now we have two repeated messages, but you have only inserted one.

To fix this problem we must change our controller and use redirect keyword on create method to redirect to a method of controller that finds all inserted messages.

When a new message is created (create method), a redirect to /list is returned, then showResults method is called, and returns a list with all inserted messages. Remember to change th:action from form tag to /insert too.

And now if you execute the same process as before, no multiple insertions occur.


And as final step let's see how to implement validation with Thymeleaf.

First thing is adding Jsr-303 provider into our pom. In this case Hibernate-Validator.

Next step is changing our model by for example creating a length constraint in phone field:

private String phone;

To trigger validation of a @Controller input, you must annotate input arguments with @Valid. So our controller is modified to:

And finally modify form page so when an error occurs, a message is shown.

First a new CSS style is created for showing error message:

See that in previous style we are defining an img folder so new static resource resolution in servlet-context.xml as done with css and js folders must be registered.

And finally in index.html a new div is created for showing errors:

For showing errors, #fields variable is used. This variable is provided by Thymeleaf and contains all errors bound by Validation Framework. Note that star '*' is used as errors function parameters for returning all errors produced by all form fields, but Thymeleaf allows you to specify only one particular field.


From this post I have learned some interesting points:

  • With new HTML5 tags, some Javascript validation (like entering well-formatted email) is not required anymore.
  • CSS 3 shadows and gradients properties allow us to create amazing forms without using complicated structures of images.
  • Thymeleaf is an amazing template engine, in fact for me a real way for creating prototypes and final code at once. 
  • Thymeleaf is a young project, and for example does not support jQuery by default, but exists   a Thymeleaf dialect that integrate it. I think that in nearest future it will be a template engine to be consider.

Hope you find Thymeleaf useful too.

Download Code.


viernes, noviembre 18, 2011

What a wicked game you play, To make me feel this way, What a wicked thing to do, To let me dream of you ( Wicked Game - Chris Isaak)

In my previous post I was talking about how to create a service using Jdk service provider. In current post I am going to talk about how to implement your own Jsr223 Script Engine. And as you will see, script engines are a kind of Jdk service providers, so instead of creating your own set of interfaces, we are going to see how to implement a service provider of an already defined service. 

Moreover we are going to see how we can convert a scripting language expression evaluator (in this case Spring EL) to be Jsr-223 compliant.

First of all for those who do not know what is Jsr-223 specification (or Java Scripting API), Jsr-223 is a scripting language independent framework for using script engines from Java code. Thanks of Jsr-223, we only use javax.script package instead of importing language specific classes.

For example using Spring EL scripting language, requires you import in your business class at least two Spring classes ExpressionParser and SpelExpressionParser, and if you want to use another scripting language, more specific vendor classes should be added, so your code is tied to script parser used.

If you use Java Scripting API, two classes are required, ScriptEngineFactory and ScriptEngine, regardless of the language used. And this occurs because ScriptEngine is an interface returned by ScriptEngineFactory service.

Let's start coding:

First class to implement is ScriptEngineFactory and is responsible of creating a new ScriptEngine. It must implement ScriptEngineFactory interface and its implementation will be the service provider of Scripting API.

First part of class is where we are defining what is the name of script language used to get the engine, the version of language (I have chosen Spring version), and version of engine.

Then three special methods:

  • getMethodCallSyntax: returns a String which can be used to invoke a method of a Java object using the syntax of the supported scripting language. In case spEL, the equivalent of calling a Java method from script, is using Types with special T operator.
  • getOutputStream: returns a String that can be used as a statement to display the specified String using the syntax of the supported scripting language. In case of spEL, there is no output stream so an unsupported exception is thrown.
  • getProgram: returns a valid scripting language executable progam with given statements. As previous method, an unsupported exception is thrown.

and finally the most important method getScriptEngine, which must return an implementation of ScriptEngine interface. In this case the Spring EL script engine. Let's see how spEL ScriptEngine is implemented.

First of all class extends from AbstractScriptEngine, which provides implementation for several of the variants of the eval method. Compilable interface is implemented too. ScriptEngines that implements this interface can compile scripts so any further execution of expression does not require any recompilation.

Most important method is eval which should cause immediate script execution using vendor library.

Main purpose of this class is adapt Jsr-223 classes to Spring EL classes. If you look carefully this class, it contains a private inner class that extends CompiledScript. This class is responsible of storing compiled expression, so subsequent calls of eval method requires no reparsing. This class is returned when compile method is called.

As final note spEL language contains some features that go beyond a standard script like registering Java functions into script, referencing Spring Beans, expression templating or navigation through properties of root objects. Of all of these features I think it would be useful having root objects support in Jsr-223 implementation, so I have coded a special attribute named "root". So if you set an attribute to script context with name "root",  attribute's content will be treated as root object.

Before implementing this solution I wondered another possibilities like not implementing root objects, or using Adapter pattern implementing two interfaces ScriptContext and EvaluationContext, but I dismissed because there were duplicated methods (different signature, same behaviour), and from developer's point of view  could be a bit confusing. Moreover this approach implies that caller should know that are running spEL script. Also I planned of using MethodResolver or PropertyResolver but was rejected because spEL would have been extended.

With attribute approach, if you are not using root objects, there are no differences between using Scripting API with Javascript, Groovy or spEL.

And finally service configuration. Create META-INF/services directory into resources folder, and create javax.script.ScriptEngineFactory file; this is the full qualified name of service interface with next content:

And that's all about implementation, with next unit tests you will see clearly how is used:

First one is testing that SpelScriptEngine is returned by ScriptEngineManager.

Not complicated, it is used as you would use for retrieving Javascript engine. Short name is used as engine identifier.

And next unit test contains some assertions about how some Spring EL features are used with ScriptEngine rather than SpelExpressionParser.

Notice how in first test, SpelScriptEngineImpl.ROOT_OBJECT constant is used, so Inventor instance is specified as root object.

Hope you found this post useful.

Feel free to use this code, I have created a git repository so you can download, branch, ...

Also I have uploaded project as zip file. Download Code.


jueves, noviembre 10, 2011

Fear of the dark, fear of the dark I have a phobia that someone's always there (Fear of the Dark - Iron Maiden)

Some time ago I wrote about how to implement your Restful Web API using Spring MVC. Read my previous  post to know about it. 

In that post it was developed a simple Rest example. For testing the application,  file was copied into a web server  (Tomcat for example), and then accessing to http://localhost:8080/RestServer/characters/1 information of character 1 was returned.

In current post I am going to explain how to transform that application to a Google App Engine and be deployed into Google's infrastructure using Maven. Of course in this case we are going to deploy a Rest Spring MVC application, but same approach can be used for migrating a Spring MVC web application (or any other application developed with other web framework) to GAE.

First of all, obviously you should create a Google Account and register a new application (remember the name because will be used in next step). After that you can start the migration.

Three changes are required, create appengine-web.xml defining application name; add server tag to settings.xml with Google account information, and modify pom.xml for adding GAE plugin and its dependencies.

Let's start with appengine-web.xml. This file is used by GAE to configure application and is created into WEB-INF directory (at same level of web.xml).

The most important field is application tag. This tag contains the name of our application (defined when you register a new Google Application).

Other tags are version, system properties and environment variables, and misc configuration like if you want a precompilation to enhance performance or if your application requires sessions.

And your project should not be modified anymore, now only Maven files will be touched.

In settings.xml, account information should be added:

See that it is as easy as registering any other server in Maven.

And finally the most tedious part, modifying pom.xml.

First thing is adding new properties:

At first line we are defining Appengine Java SDK location. If you have already installed then insert location in this tag, if not, copy same location of this pom and simply change maven repository directory, in my case /media/share/maven_repo, to yours. Typically your Maven repository location will be  /home/user/.m2/repositories. Maven will download SDK for you at deploy time.

Next step is adding Maven GAE repository.

Because our project is dummy project, Datanucleus are not used. In case of more complex projects, that database access is required using, for example JDO, next dependencies should be added:

And in case you are using Datanucleusmaven-datanucleus-plugin should be registered. Take care to configure it properly depending on your project. 

Now Google App Engine dependencies are added.

Then if you want to test GAE functionalities (not used in our dummy project), next GAE libraries are added:

Next change is a modification on maven-war-plugin including appengine-web.xml into generated package:

And finally adding maven-gae-plugin and configuring it to upload application to appspot.

See that <serviceId> tag contains the server name defined previously in settings.xml file.

Also if you are using maven-release-plugin you can upload application to the appspot automatically, during release:perform goal:

Now run gae:deploy goal. If you have already installed Appengine Java SDK, then your application will be uploaded to your GAE site. But if it is the first time you run the plugin, you will receive an error. Do not panic, this error occurs because Maven plugin does not find Appengine SDK into directory you specified in <gae.home> tag. But if you have configured gae.home location into your local Maven repository, simply run gae:unpack goal, and SDK will be installed correctly so when you rerun gae:deploy your application will be uploaded into Google infrastructure. 

In post example you can go to and character information in JSON format is displayed into your browser.

As I have noted at the beginning of the post, the same process can be used for any web application, not only for Spring Rest MVC.

Because of teaching purpose all modifications have been made into application pom. My advice is that you create a parent pom with GAE related tags, so each project that must be uploaded into Google App Engine extends from same pom file.

I wish you have found this post useful.

This week I am at devoxx, meet me there ;) I will be speaking on Thursday 17 at 13:00 about Speeding Up Javascript & CSS Download Times With Aggregation and Minification

Full pom file:

Download Code.

lunes, noviembre 07, 2011

I en una paret al fons imprès en blanc i negre hi havia un pòster d'en Godard. Potser ell em podria dir-me perquè em ballava el cap. (Jean Luc - Els Amics de les Arts)

Although you can think that Comma-Separated Values (CSV) files are simple files where each value is separated by commas, it is far from reality. The most important part of CSV files are delimiters, and one can think that the delimiter, as type name suggests, is comma. But this assumption is not always true and CSV is often applied to files using other delimiters. Typical example is found in countries where comma (,) is used as decimal separator, because you would have no way to discern between decimal number or separator, semicolon (;) is used.

If your application is distributed across different countries and your application should support  Comma-Separated Values files, then you should take care about this important fact.

Let's see how can we resolve this problem so we can read CSV files depending on country. 

For reading CSV files we are going to use openCSV library. This API contains one class for reading CSV files (CsvReader) and another for writing (CsvWriter). By default it uses comma as column delimiter, but you can also inform which delimiter character must be used.

So the problem is how to know which delimiter we should use. And for resolving this problem we can use DecimalFormatSymbols class. This class represents the set of symbols needed to format numbers.

DecimalFormatSymbols has a method called getDecimalSeparator() that as his name suggests returns a decimal symbol, comma (,) in case of countries like Germany, and dot (.) in case US for example. So with a simple ternary you could know which delimiter is used in CSV files depending on locale.

So final class will look like:

And previous factory can be instantiated with Spring and injecting delimiter, using Spring Expression module.

See that thanks of Spring Expression delimiter is injected directly into class.

I think it is not difficult to implement an application that can read Localized Comma-Separated Values files, and can avoid having problems when application is distributed around the world.

Full Code:


miércoles, noviembre 02, 2011

En ti puedo ver la libertad, Tu me haces sentir que puedo volar, Y se que aquí es mi lugar, Y se que a ti yo quiero amar (Cuando Me Miras Asi - Cristian Castro)

From ServiceLoader javadoc: A service is a well-known set of interfaces and classes. A service provider is a specific implementation of a service. The classes in a provider typically implement the interfaces and subclass the classes defined in the service itself.

Since JDK 6, a simple service-provider loading facility is implemented. As is suggested it is simple, you cannot understand that implementation as a complex system for implementing plugins for your application, but can help you in many situations where you want  implementations of a service could be discovered by other module automatically.

What I really like about using JDK Services is that your services do not have any dependency to any class. Moreover for registering a new implementation of a service, you just have to put jar file into classpath and nothing more.

Now I will explain the service we are going to implement, and then I will show you how to code it.

We want to implement a system that depending on kind of structured input (comma-separated value, tab-separated value, ...) returns a String[] of each value; so for example you can receive input a,b,c,d or 1<tab>2<tab>3<tab>4 and the system should return an array with  [a, b, c, d] or [1, 2, 3, 4].

So our system will have three Java projects.

One defining service contract (an interface) and, because of teaching purpose, a main class where internet media type, for example text/csv, is received with input data. Then using a factory class that I have created, it will ask which registered service can transform input to String[].

And two projects each one implementing a service following defined contract, one for comma-separated values and another one for tab-separated values.

Let's see the code:

Main project (reader) is composed by an interface, a main class and a factory class.

The most important part is Decode interface which defines service contract.

Two operations are defined, one that returns if service supports given input, and another that transforms data to String[].

DecodeFactory class is responsible for finding an implementation service that supports required encoding. In fact, this class encapsulates java.util.ServiceLoader calls. ServiceLoader class is in charge of load registered services.

At line 3 we are loading all services that are registered in classpath. At line 7 we only iterate through all services asking if given encoding name is supported.

And finally main class.

And now if you run this class with java -jar reader.jar "text/cvs" "a, b, c, d", an UnsupportedEncodingException will be thrown. Now we are going to implement our first service. Note that reader project will not be modified nor recompiled.

First service we are going to implement is one that can support comma-separated values encoding. Only one class and one file are important.

CSV class is an implementation of Decode interface and transforms comma-separated values.

As you can see a simple StringTokenizer class. Only take care that this class is Locale sensitive, countries where comma (,) is used as decimal delimiter, separation character is semicolon (;).

And next important file is a file that is placed into META-INF. This file contains a pointer to service implementation class.

This file should be in META-INF/services and should be called as interface full qualified name. In this case org.alexsotob.reader.Decode. And its content should be service implementation full qualified name.

And now you can package this project, and you can reexecute reader project but with generated jar (csv.jar) into classpath. And now output will be an array with a, b, c and d characters instead of unsupported exception.

See that reader project has not been modified and its behaviour has been changed. Now you can develop new implementations for decoding new inputs, and you should only take care of copying them into classpath.

Only take care that all services should have a default constructor with no arguments.

And for those who use Spring Framework, Services are also supported through three different FactoryBeans, ServiceFactoryBean, ServiceListFactoryBean, ServiceLoaderFactoryBean.

As I have noted at start of this post, JDK services is a simple (yet powerful) solution if you need to create a simple plugins system. In my case it has been enough with JDK services, and I have never required more complex structure; but in case you are thinking about a complete plugin solution you can use JPF that offers a solution like Eclipse plugins, or even OSGI.

I wish you have found this post useful and now you know (if you didn't know yet), an easy solution to develop modules that are plugged and play.