We are using Vaadin since a few months. There are a few things we missed in the core framework.
List data handling
In almost every use case where you want to get a list of values (for example a table with data) you should never get the whole list in one peace. I think Vaadin should get massive improvements about that aspect. We always implement a paginator as a Java Iterator or in some cases a Value List Handler… It should be easier to consume such datasources…
Data handling
We don’t want to mix up Business Layer with the GUI, in my opinion there is no need of other data items / container than the bean thing.
JPA Container is nice to get really short development times but we don’t like to mix up GUI with that kind of stuff.
We more like the service oriented development with a middleware, so we do just consume services.
Event handling
It would be great if the blackboard pattern implementation would be part of the Vaadin framework.
Web oriented parts
Stuff like a view and url handler should be part of Vaadin.
Forms
The current form concept is easy to use and you get really short development times for simple forms. Maybe there is some place for improvements like the FormBinder addon.
Experience
Vaadin is very powerful and we really like it. We’ve never seen a project with such a good documentation and so many code examples.
Great to hear you have enjoyed. Some comments below that might make you like Vaadin even more.
This is issue has indeed been identified. Still in some use cases, UI components couldn’t work that well with just e.g. Iterable interface. There is a wiki page about container related changes for next major version in dev.vaadin.com. Total rewrite for that area is not on the table atm, but some enhancements are on the way. http://dev.vaadin.com/wiki/Vaadin7/Features/ComponentContainers
That is a wise decision to do in some projects. We often do similar things in our projects too. But it is also good to point out that MS Excel with VBA is the most common programming environment in the world. Most applications don’t need complex n tier architecture. If you have e.g. service layer you can simple use objects received from it with BeanItem and BeanItemContainer to bind that data. For smaller apps I’d really urge to reconsider JPAContainer. Simple project structure and rapid development time might save your (or your customers) money in some projects.
There is EventRouter class in Vaadin that you are probably looking for. The class is not that much advertised in our book, but the helper class has always been there and it can be used in you own apps. You can also use any third party implementation which I’m sure you can find several. Even in the Directory there is an add-on called BlackBoard.
This kind of stuff has previously been bit hidden from developers due to “terminal independence” approach that Vaadin and its ancestors have used. This will partly change in next major version, but still we’ll mostly try to be UI library instead of “framework” dictating exactly how you should build you app.
There is lots of room for improvements on this area. CustomField is another important “must have feature”. Next major version will have both of this kind of features in some form. Until that, we can just be happy to have a working plugin architecture (jar + method for automatically taking advantage of possible client side GWT extensions).
Thanks, I’m sure this kind of open feedback keeps our motivation high! And keep those suggestions coming. We do listen.
I think that using the Vaadin UI event router to handle business-level logic is a bad idea. It mixes together two different notions of events, and the Vaadin event router is much more difficult to code compared to using the BlackBoard or another event bus.
EventRouter in Vaadin is a generic helper class and it has no dependencies to UI components. If it is difficult to use, we should definitely fix that. It might also help framework development.