after using JSF 1.2 with Facelets for some time and having moved to Vaadin here’s some opinions about the experience.
In general it has been a very pleasant experience:
everything is in one file, no going back and through beans, xhtml files and faces-config
more errors detected at compile time (no typos in xml etc.)
fast deploy & load time
no weird problems with odd lifecycle (messages not shown, request scoped tables not working etc.)
Some cons though:
not as much type safety as I had imagined: conceptually you often just replace {#foo.bar} (JSF) with someMethod(foo, “bar”) (Vaadin). Unfortunately there’s not much possibilities for improvement, unless we get method handles (with closures) in Java 7.
data model feels really complex compared to JSF. In JSF you just use the plain objects and the only “real” data model interface is used with tables (ie. only the Container part is visible to user and similar than BeanItem stuff is “hardcoded” inside). In Vaadin there’s lots of item, itemId, property etc. stuff. For example, when adding item to a select: public Item addItem(Object itemId). The method add
Item takes
ItemId as a parameter and
returns Item . Not really self-explanatory. In JSF you bind the component to List, and the SelectItem has a descriptive constuctor: SelectItem(java.lang.Object value, java.lang.String label) and a getLabel method you can override if needed. No playing around with setItemCaption or setItemCaptionMode etc. I admit Vaadin style is much more flexible but also much more error prone. I would prefer the very clear and simple JSF-style solution.
Some other thoughts:
no scoping at all, but I’m not sure if it is actually needed at all. Conversation scope might be useful with JPA, but probably doesn’t belong to Vaadin.
Need to have everything serializable feels bit odd, but there’s probably good grounds for it.
As a conclusion, a really nice framework, even I personally don’t favor the data model very much.
Thank you for this summary, I enjoyed reading it. Especially the cons and thoughts, since we’re currently trying to decide what (potentially major) changes to include in Vaadin 7…
One thing though (and this is obviously not very clear, I’m not sure how/where we should document this):
There is actually no need to have everything serializable - unless you’re deploying to Google App Engine (or something else that needs to serialize the session). But in order to support GAE, the Vaadin core needs to be serializable. You can safely ignore the warnings about serialization if you do not need it…
I think you are right. The API is bit too generic to be intuitive. But powerful: yes. And luckily there are a few helpers to make it easier to use.
I’d like to advertise one solution I made to help with the simple collection and array cases:
http://vaadin.com/addon/collectioncontainer . The idea is that you can do with a one-liner, if you only have a Collection or an array of pojos you want to bind to a Select or a Table.
Also for completely different approach (pull type datamodel) you could try out
the LazyContainer .
I think it’s good practice to keep everything serializable in the session. Even if you don’t think you need it now, it could hold you back if you’re planning on an application with a lot of users. In that case, you’d preferably deploy your application to a cluster, and if the state of the UI can’t be serialized then you lose failover in case an instance in the cluster fails.
Even with a single Tomcat/app server installation, the container could choose to store the session information at any time (typically if the session isn’t very active and resources are running low). To be honest, I typically leave it out when writing quick tests or demos, so I can’t say I always follow my own advice.
