ace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Offermans <marcel.offerm...@luminis.nl>
Subject Re: Moving the web UI to Vaadin...
Date Wed, 13 Oct 2010 23:07:40 GMT
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


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message