Yep, this is really important. A bit of a rhetorical question: Why not design wicket.next with modularity as a first-class requirement?
On Sep 20, 2011, at 7:43 PM, Ben Tilford wrote: > 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 <dretzl...@gmail.com> 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 <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. >>> >>
