Index
Elsewhere
Navigation
« Smart and funny... some people just make you sick | Main | Adventures with Scala and Vaadin - Detour 1 "Comments" »
Thursday
Jul092009

Adventures with Scala and Vaadin - Part 6

I've jumped ahead in the book. The next few sections cover a variety of different components where we could use the same sort of tricks with closures and extension methods to make the interactions a little nicer but I don't think there'd be much value to that. I've skipped ahead to page 93 where we encounter forms for the first time.

Forms are interesting because they introduce bean-bindng - automatically associating form fields with properties of Java objects.

I'm a little surprised to find this in here, on one hand it feels like a step towards the 'Naked Objects' approach which I really like but on the other hand, I'm not sure why the Form abstraction is needed in a framework that has such powerful Ajax functionality. I have my suspicions that this is a holdover from an earlier time, a time when Vaadin was more request/response oriented. It is interesting nonetheless, and I'll see where it leads me.

I am expecting to run into some problems here. Scala code doesn't always look the way I'd naively hope from the Java side of the fence.

So, here we go. Version 1. Imagine we were building a Pirate administration tool...


package spike

import com.vaadin.Application
import com.vaadin.data.util.BeanItem
import com.vaadin.ui._

class Pirate {
private var name: String = ""
private var weight: Int = 0

def getName: String = {
return name
}

def setName(newName: String): Unit = {
this.name = newName
}

def getWeight: Int = {
return weight
}

def setWeight(newWeight: Int): Unit = {
this.weight = newWeight
}
}

class SpikeApplication3 extends Application {
override def init: Unit = {
val mainWindow = new Window("And now... a form.")

val form = new Form()
form.setCaption("This be the caption. Yes it be, it do!")
form.setDescription("What we 'ave 'ere is a tool fur the displayin' o' pirates.")

form.setItemDataSource(new BeanItem(new Pirate))

form.setValidationVisible(true)

mainWindow.addComponent(form)
setMainWindow(mainWindow)
}
}


That works pretty well. I defined a Pirate class and adhered to the gnarly Java syntax for defining Bean properties and, hey presto, we have a form with two bean properties nicely represented on it.

The property syntax is just plain fugly though. Let's get to the Scala pimp action.


package spike

import com.vaadin.Application
import com.vaadin.data.util.BeanItem
import com.vaadin.ui._
import reflect.BeanProperty

class Pirate {
@BeanProperty var name: String = ""
@BeanProperty var weight: Int = 0
}

class SpikeApplication3 extends Application {
override def init: Unit = {
val mainWindow = new Window("And now... a form.")

val form = new Form()
form.setCaption("This be the caption. Yes it be, it do!")
form.setDescription("What we 'ave 'ere is a tool fur the displayin' o' pirates.")

form.setItemDataSource(new BeanItem(new Pirate))

form.setValidationVisible(true)

mainWindow.addComponent(form)
setMainWindow(mainWindow)
}
}


That's much better. We've replaced the fuglyness with an annotation. This annotation is interesting. From a Scala perspective, it doesn't really do anything. From a Java perspective there's a world of difference. The annotation tells the scala compiler that the output should include Bean style getters and setters for the this property. In effect the annotation provokes the compiler into doing a chunk more work so that we don't have to.

I'm not happy though. I always hated the Java convention whereby beans should have no-arg constructors. The number of bugs that I've seen stemming from improperly initialised objects is, well, it's too damn many.


class Pirate(@BeanProperty var name: String, @BeanProperty var weight: Int)


There's our Bean class, replete with two arg constructor. I like it.

Another experiment. Scala's BeanDisplayName should be able to be used to change the label placed on the field - assuming the Vadiin developers have gone through the BeanInfo for the class rather than using simple reflection to guess at properties.


class Pirate(@BeanProperty var name: String, @BeanProperty var weight: Int) {
@BeanProperty @BeanDisplayName("Landlubbers put to the sword") var victims: Long = 0
}


Sadly this doesn't work. The field that appears in the form is labelled Victims rather than 'Landlubbers put to the sword'. Whether this is a hole in Vaadin, a problem with Scala, a problem with the Scala to Java integration or just because I screwed up I can't say.

References (4)

References allow you to track sources for this article, as well as articles that were written in response to this article.
  • Response
    you instead, amount the rings and attenuated down your choices again baddest the best. this section of jewellery abreast from getting the best allowance you could
  • Response
    Rob Lally : Robert Lally : Renaissance Technologist - Blog - Adventures with Scala and Vaadin - Part 6
  • Response
    NFL is actually one particular of the greatest sports in America. It has a important following.
  • Response
    Response: Free Print Banner

Reader Comments (3)

Forms in Vaadin are completely optional helpers. Their sole purpose is to make creating "editors" for item-objects. It it totally ok to just skip Form-class and build forms "manually" field-by-field.

July 10, 2009 | Unregistered CommenterJoonas

Unfortunately Vaadin does not support BeanDisplayName. Created a feature request into backlog for that: http://dev.vaadin.com/ticket/3135

July 10, 2009 | Unregistered CommenterJoonas

Hey Joonas,

Don't beat yourself up on the display name thing. Java Beans are actually quite complicated by the time you add in BeanInfo objects plus change listeners and property change veto listeners. But nobody really uses that stuff, in fact I doubt many people even know that the Bean spec covers anything beyond 'write getters and setters'.

http://java.sun.com/javase/technologies/desktop/javabeans/index.jsp

R.

July 10, 2009 | Unregistered Commenterrob

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Post:
 
All HTML will be escaped. Hyperlinks will be created for URLs automatically.