With the js framework suggestions I havn't seen anyone mention a module system like require.js this would be something I'd wan't to see used. If something like jQuery gets included without a module system it would only be a matter of time until jQuery.next was released and someone wants to use it. A module system would allow the app developer to specify dependency versions without causing conflicts with those provided by the library (Wicket).
On Tue, Sep 20, 2011 at 12:59 PM, Dan Retzlaff <[email protected]> wrote: > 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 <[email protected] > >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. > > >
