> Even though the difference in complexity is not that big in example, in > large applications it really makes a difference.
Yes, the example looks pretty much like Wicket. IMO what will make a *real* difference is using another language - Java is Java with its strengths and weaknesses; on the verbosity side there's not much to be done. Anyway, thanks for updating your comparison table and I wish you the best of lucks with your project. Francisco 2009/7/6 Joonas Lehtinen <[email protected]>: > > 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: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
