On Wed, Sep 21, 2011 at 2:43 AM, Ben Tilford <b...@tilford.info> 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).
Actually I did mention it earlier in this thread. Search for CommonJS/AMD. Even if we choose JQuery (this is the decision for now) we will allow to load custom ResourceReference. This way Wicket may come with version X of the JS library and the user will be able to do something like: getAjaxSettings().setJSReference(new PackageResourceReference(SomeUserClass.class, "jquery-X+1.min.js")) If we do the same for wicket-ajax.js then there is no need to use an adapter as I suggested in the same mail earlier. This way the user may use YUI instead with its own impl of wicket-ajax.js (e.g. translation from JQuery to YUI) > > > 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. >> > >> > -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com
