http://h2g2java.blessedgeek.com/2010/05/vaadin.html http://h2g2java.blessedgeek.com/2010/05/using-vaadin-with-google-app-engine.html
Vaadin is very attractive and manageable. With Vaadin you do not have to worry about RPC. You can declare objects and classes and presume their visibility would spread across the whole web app - whereas, in pure GWT, you have to propagate objects through RPC. In Vaadin, if the propagation of the visibility of an object crosses the server-client line, Vaadin communication takes care of that for you. As long as those classes implements Serializable. It is quit difficult to do mash-ups with Vaadin. It does not provide any means for its client to communicate with a server outside its own box. This because the server dictates the behaviour of the client. Vaadin projects a skeletal client using GWT widgets. Those GWT widgets are dysfunctional on their own. They need the server to fill themselves up with behaviour and appearances. So if you want to communicate with Yahoo or OpenId, you cannot do it thro the client. So if your 3rd party app requires you to submit a web form with a callback, you have to send the form thro the server and and have the server process the callback. This is very bad for OAuth and OpenId, which requires client- side authentication. I am not aware of any mechanism where server-side Vaadin would facilitate client-to-3rdparty server authentication. In fact, does OAuth or OpenId even allows that? You know, authentication tunnelling. As a browser-user, I should be rather uncomfortable with authentication tunnelling if that were possible. A number of Vaadin enthusiasts have projected the idea that it is very simple to deploy plain old GWT widgets in Vaadin, simply wrapping them with a Vaadin widgetset, which involves motions on both the client and the server. Vaadin has a very rich set of widgets so you almost never need to deploy any plain old GWT widget. If you do, it means that widget is so complex that you should pay Vaadin to do it for you. SmartGWT and all the other yucks - they require eyebrow-sweating precision and skill and their stability toggles like a switch. Or, even have bait-and-switch mutating open-source licensing. They ever refuse to behave properly in the presence of GWT. Vaadin is very stable, dependable and robust. Vaadin is very maintainable, usable and programmable as long as your app is a single-self-service application. I had an application which uses objectify on the GWT servlet. I attempted to convert it to Vaadin and had to wrap it around a widgetset. Poof! The line between client and server in Vaadin is so blur that widgetset compilation asks for the source-code of javax.persistence to continue compiling the widgetset successfully. So I find plain old GWT so much more customisable, controllable, programmable and comprehensive. Once you understand RPC - it's a breeze. It's an advantage having a clear and hard line drawn between client and server. Vaadin's blurring this line is elegant but it constraints my freedom of movement by having too many constraints. They do everythng for you and won't allow any loose ends untied for you to choose your own way of tying your shoelaces. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
