Hello Brian, On 13 Oct 2010, at 17:33 , Brian Topping wrote:
> I'm surprised nobody has mentioned Wicket [0]. In an architect role a couple > of years ago, I got a couple of diehard GWT folks to give Wicket a try, and > we finished the project. Recently, one of the two started showing up on the > wicket-user list, so he's clearly found it to be a preferrable environment. > I can't speak for someone who's used GWT and switched, but I think it says a > lot that someone would stick with it like that. I can't speak for others either, but I am aware of Wicket and have used it. Probably not as extensively as you, but I even gave it a spin in an OSGi context (even before the Pax Wicket project got published, so it's been a while). More recently, Toni and I did a project using Wicket and OSGi again. > Google will return lots of results for the search "gwt versus wicket", but > one that has been considered a standout over the years is [1]. [2] provides > some great side-by-side examples of Wicket code and live results. Those are indeed some nice examples. > Wicket is structured a bit closer to how I understand Rails to be structured, > with a JavaScript kernel that gets downloaded to the client. Wicket provides > a rich Java-based API that uses this kernel to manipulate the DOM on the > client. There is no recompilation for JavaScript, and the runtime is fast, > so there are no speed issues, either in development or deployment. I don't think there are real speed issues with Vaadin either (just to set the record straight). The main observation is that Vaadin, like Wicket, has a server side session that, depending on your application and its design, might contain a considerable amount of state. GWT might be a bit better there, as it has more client side state. > As far as modularity, Wicket is completely modular without hacks. It is an > Apache TLP. Yes, it can be modularized quite nicely, mainly because it does not use a huge and static XML file to specify page flow (something I remember from Struts). > As full disclosure, Wicket can be tricky in an OSGi environment because it > serializes page object graphs for handling the back button. Pax Wicket > provides one solution to the problem, and many experienced folks roll their > own. The problem is created when different OSGi modules instantiate and > contribute objects to a graph. The graph can be serialized without incident, > but deserializing a graph that contains objects contributed from different > bundles is not possible because of classloader issues. > Please let me know if there's any questions I can answer. Well, comparing Wicket to Vaadin I personally still feel that for the kind of application ACE needs to manage artifacts and targets, Vaadin provides a better starting point. It has a very rich set of controls out of the box (see http://demo.vaadin.com/sampler/ which also contains code snippets) and a programming model that fits OSGi very well. Today I spent a couple of hours getting something started and I must say I am very impressed with the speed at which I can develop controls with complex behaviour, and the Vaadin documentation is very well done. Wicket is definitely a good choice too, especially if what you're doing is more related to building some kind of website with application logic in it. The separation of HTML and code is done in a very smart way and offers great flexibility for developers and designers. Still, a model that is more like classic MVC toolkits feels more comfortable to me for this UI. As soon as I have something working that doesn't look too embarrassing, I'll commit it so everybody can take a look. :) > Cheers, Brian > > [0] http://wicket.apache.org > [1] > http://ptrthomas.wordpress.com/2008/09/04/wicket-and-gwt-compared-with-code/ > [2] http://wicket.apache.org/learn/examples/ Greetings, Marcel
