Play Framework HTML5 input elements

The built in Play input elements are fairly restrictive in that you can’t specify the input type. I wrote a helper template that you can use to generate input elements which have HTML5 type attributes such as url, email, number, search etc. etc.

All you have to do is call the template method, passing the HTML input type as a parameter. For example:

@helper.html5.input(form("website"), '_label -> "Website:", 'type -> "url")

If you have a form field mapped as a then the template will automatically infer it’s type so you don’t have to pass the type attribute in with your html attributes:

@helper.html5.input(form("email"), '_label -> "Email:")

If your field has the required constraint, e.g. it is a “nonEmptyText” then the template will add the HTML5 “required” attribute to the field as well.

You can get the source code here.

Woes with Scala native types, Spring, JPA and FreeMarker

I’m working on a project using Scala, Spring, JPA and FreeMarker (as you probably guessed from the title of the blog post). I love working with Scala because for the most part, it makes my code more succinct and it is really exciting to work with. I mean, there are obviously other reasons but those are two big ones.

What I don’t like is having to convert between Scala and Java equivalents, but sadly it is unavoidable. The scala.collection.JavaConverters and scala.collection.JavaConversions objects make this a lot easier through implicit and explicit conversions but it does make you wonder what the performance hit is…

I mostly choose to ignore that there is a performance hit – performance problems are a happy problem anyway right?…and at the moment the benefits of being able to write code in Scala greatly outweigh any of my worries.

I use Scala types wherever possible in this project i.e. List, BigDecimal etc. but sometimes it’s just not possible. My domain objects have to use Java types because the JPA vendor doesn’t know how to translate the Scala types into SQL column types. The same goes for objects that are going to be passed to FreeMarker. FreeMarker cannot iterate over a Scala list using the <#list scalaList as item> syntax as you normally would since it doesn’t “know” what a Scala List is. As far as FreeMarker is concerned a Scala List is a java.lang.Object (see

My repositories are generated dynamically by Spring. Basically you define an interface and Spring magically generates a class that extends Spring’s JpaRepository and implements your interface. There is no two ways about it, I want this magic, but it means that the “interfaces” (which are coded as traits in Scala) have to return Java lists for findAll or findBy operations – boo.

Overall it isn’t actually that much of a pain, so I don’t know why I’m complaining about it. It is just something that slightly tarnishes the code, but I guess I can live with it. After all I did decide to use a bunch of Java frameworks with my Scala code. Why didn’t I just use Scala frameworks? Well, mostly because I’m pretty mad, but I’m not completely insane. I figured switching from Java to Scala was a big enough brain realignment without changing everything else I’m used to using as well.