I’ll try again… Sadly, the previous response I wrote was lost with a “No Permission” type of error and doing a BACK in my browser lost all of what I had typed. Not good!
Anyway, I’m sure no two projects will have the same experiences, but Yozons essentially ported our older product that relied on a JSP+Servlet UI when we created Open eSignForms. We used the opportunity to not only put in a more modern UI, but we also changed quite a bit in our back-end to support new capabilities as well as better support Vaadin itself and a new UI in general.
We evaluated Dojo, YUI, ExtJS, GWT and SmartGWT before we settled on Vaadin. It was actually a snide comment in one of those forums from a brainiac with no social sense that mentioned Vaadin, which I’d never heard of. Of course, his opinion was that Vaadin was an oddball, server-centric UI that could not compete with a true JS front-end.
We didn’t have lots of JS experience, and in our evaluations, we had lots of work with DTOs, using JSON, implementing the event models to transfer the data back and forth, etc. It was a lot of work, but was doable. It may even be easier today, since it was 1.5 years ago we did that eval.
However, when we discovered Vaadin, it felt more natural to us as it still does most of its magic on the server where we feel we have more control, better security, etc. I guess the security side remains to be seen since we don’t really know how easy/hard it is for someone to mess with the UIDL to try to do an operation a user wouldn’t otherwise be allowed to perform. Then again, a lot of JSP/servlet programmers probably failed to check the security of operations and the validity of all params coming in, assuming that users were not tampering with the POST data (a bad assumption if your app needs to be secure).
We still have not settled whether we prefer to use JavaBeans with the related BeanItem/BeanItemContainer, or just use the Vaadin Item/IndexedContainer for most of our work. The beans seem easier, and they are for simple stuff, but we found when porting that a lot of our java classes were not well suited to be used directly, so we ended up created new javabean classes for the UI interface. This felt like the DTO issue all over again, especially since a change to the bean wouldn’t then automatically be pushed into the items/containers. Similar issues with Selection lists arose because we made more use of Lists than the Set interface chosen by Vaadin, so we had to essentially create adapter methods for those. In the end, once you get used to Item/Property, they can be used directly with ease, and seem to require no more code than javabeans unless your existing classes all match up nicely for UI needs.
One concern we had was with performance of the UI since it requires the server to generate it all, but we’ve not had any real issues. It seems faster than when we used JSPs. Obviously, if you have a UI-intensive widget, it’s best if that can all be done in JS in the browser to avoid lots of server communications. We don’t have much, but we did integrate CKEditor, and we found it works fine because most of the work remains in the JS code of CKEditor, and we only have to deal with the server to load the initial state, and then handle the SAVE button, so it remains responsive to the user.
Our old system used a common JSP list of items and you’d click on them to bring up another JSP where you changed it. This maps nicely to the Table+Form model of Vaadin, but with a splitpanel, you can avoid the page swaps that the JSP did. Of course, you should reconsider some UI design items since you can now make use of components like a TreeTable and drag & drop, a feature we really like for re-ordering lists, an ugly concept in a JSP world!
Good luck with your project no matter your decision regarding the use of Vaadin. We are still happy with our decision, though we’ll never know if we’d have been happier with any of the others since that’s a path never taken!
