Well said, Juliano! Thanks for your contribution. In my experience the awkward parts of interacting with JS/JQuery objects from Wicket are 1. Converting model objects to/from JS strings 2. Invoking JS initialization functions (with data arguments) at the right time, i.e. when a certain Wicket component get (re)rendered. 3. Keeping track of server-side behavior callback URLs, and invoking them with additional parameters from within JS functions.
As has been said, there's nothing particularly hard about these, but in the end there tends to be more boiler plate than business. Re #1, Wicket has a nice IConverter framework for object/string marshalling used mostly by FormComponents. Maybe this could be leveraged to push/pull model values to/from JavaScript without explicit application code. Re #2, what if components could be told to export their model values into the DOM, and the value were accessible through something like http://api.jquery.com/data/? Then a normal (anonymous) dom/document ready event handler can be used to init the JS world without additional Java. Re #3, maybe the Wicket JS API can include a way to initiate a request, similar to form submit, to push new values back to the server. The main difference with actual form submit is that you needn't have <form> and <input> tags and wicket:ids; the existing components and their models are sufficient. This may be a naive suggestion, though, since most of the form validation process would still need to apply, and need to be customizable per component / model object. Just a few suggestions. Please don't pull your punches tearing them down. :) Dan On Tue, Sep 20, 2011 at 10:12 AM, Juliano Viana <juli...@logicstyle.com>wrote: > Hi, > > I have been following this discussion and I think its not fair to call > Wicket Ajax support broken. > I started using Wicket back in 2007, and the environment then was: > > - Support for IE 6 was a must. > - JavaScript on the browser was still slow and unreliable > - The applications where designed to work mostly with standard HTTP > request/replies, with only some specific functionalities being implemented > in Ajax. > > Since then the web has evolved a lot - IE 6 is dead (or dying), Google > Chrome raised the bar for the JavaScript engines and most modern browsers > now support WebSockets for low latency communications. We are now at the > point where some people are deciding not to use a web framework at all, and > rely instead on JavaScript plus RESTful web services (Google Plus is an > example of such an architecture). > > Wicket is still very good at what it does, specially considering the > environment in which it evolved. I personally dont think the API is an > issue - every API is a compromise and once you learn to live within its > limitations there is very little you can't do with Wicket Ajax one way or > another. > > The issue I see is: there is a lot of opportunity for making applications a > lot more interactive by moving processing to the browser. GWT does that by > compiling Java into JavaScript, but my latest experiences with JavaScript > have convinced me that this step is probably unnecessary - you can be > pretty > confident that once you use a framework like JQuery your code will run > unmodified in the major web browsers. The only thing that is not so easy to > do is to interact with the server-side state. > > This is where I believe improvements can be made - enabling JavaScript to > interact easily with Wicket models and listeners. This would make it > easier to write more compelling user interfaces by leveraging current and > future JS frameworks while preserving the Wicket component and model > structure, which is in my oppinion Wicket's strongest point. > > Regards, > - Juliano. >
