Hi all, If there are any errors in our comparison table, please accept my apologies - I wrote the original version of the table. I take care that any errors will be corrected as soon as possible. Just to clarify the situation - I think that wicket is a nice framework and really want to give it a fair comparison. In my opinion, Vaadin is better for some applications and Wicket for some.
Here are quick comments to your concerns. francisco treacy-2 wrote: > > Widget diversity & richness: > - (I guess richness means Ajax-enabled components?). You put 1 star - > but there are plenty of 3rd party Ajax components for Wicket... for > instance have a look at wicketstuff.org. > I did this comparison purely by looking at the available demos and comparing available ajax-enabled components on http://wicketstuff.org/wicket13/compref/ that I thought to represent the wicket core component set. You can browse through the core widgets (with code examples) on http://demo.vaadin.com/sampler/ Unfortunately I did not include wicketstuff - is there a (online or offline) demo available? On the other hand - I also left out all the extra Vaadin components on http://dev.vaadin.com/svn/incubator/ and from http://dev.vaadin.com/svn/contrib/ francisco treacy-2 wrote: > > And by the way, "require you > to use their AJAX API to implement AJAX functionality" is simply not > true. I have created components with jQuery or Mootools where you just > drop the jar in your classpath and don't code a single line of > JavaScript. Further, you reuse the goodness of inheritance to > structure the JavaScript contributions, like <script src="..."/> > Please explain - I thought that in order to make a wicket page "ajax enabled", you should create special Ajax callbacks and use Ajax exabled components as explained in http://wicket.apache.org/exampleajaxcounter.html In Vaadin all components and rendering is purely Ajax enabled. The above mentioned example re-written in Vaadin would look like: package com.example.counter; import com.vaadin.Application; import com.vaadin.ui.*; import com.vaadin.ui.Button.ClickEvent; public class CounterApplication extends Application { private int counter = 0; public void init() { Window mainWindow = new Window("Counter Application"); setMainWindow(mainWindow); final Label label = new Label("Not clicked yet"); mainWindow.addComponent(label); mainWindow.addComponent(new Button("Click me", new Button.ClickListener() { public void buttonClick(ClickEvent event) { label.setValue("Clicked " + (++counter) + " of times."); } })); } } Even though the difference in complexity is not that big in example, in large applications it really makes a difference. francisco treacy-2 wrote: > > Framework extensions are done in Java: > - You should tick it - extensions *are* done in Java > By framework extensions here I mean new components/widgets and as the comparison is only about RIA, I mean Ajax enabled components. In Vaadin new widgets are written in Java - both on server-side and on client-side. Client side is compiled with Google Web Toolkit to JavaScript. To read more, see: http://vaadin.com/book/-/page/gwt.html In order to create a new Ajax enabled widget for Wicket, you must write client-side with JavaScript and server-side in Java - or am I wrong here? francisco treacy-2 wrote: > > No HTML required: > - It depends. There are components that don't have associated markup. > All examples on http://wicket.apache.org/ include some HTML. In Vaadin there is no "page" concept at all. For example, the above "counter" is self-contained - you do not need any html or xml to run it. (ok, you must configure vaadin servlet in web.xml) francisco treacy-2 wrote: > > No XML configuration required: > - You should tick it - no XML configuration is required whatsoever. Of > course, web.xml but... you know. > Ooops. This is my mistake. Sorry. Will be corrected asap. francisco treacy-2 wrote: > > Web-page oriented / Framework tuned for building web-pages/sites > instead of application user interfaces: > - Well, definitions here are quite blurred. But I'd say the sweet > point of Wicket is building highly-stateful application UIs. > You are right - border is really blurred. To draw a line, we should consider what is the "normal" operating mode for the framework. Most Wicket applications require page changes and most Vaadin applications operate within a single page. francisco treacy-2 wrote: > > Commercial support & guarantees available: > - There are various companies that provide support for Wicket > Can you really buy guarantee for Wicket? Any references? Best regards, Joonas -- View this message in context: http://www.nabble.com/wicket-vs-vaadin-clarifications-tp24353170p24356576.html Sent from the Wicket - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
