i think server-side api changes should be minimal unless you heavily customized the ajax behaviors with regard to what url/scripts they use...
-igor On Mon, Sep 19, 2011 at 11:09 AM, tetsuo <[email protected]> wrote: > Ok. I'd add some kind of 'server-side-push/comet/websocket' support to the > wishlist :) > > It certainly will break the javascript side, but do you guys think these > improvements could be implemented without breaking (too much) the Java API? > > > > On Mon, Sep 19, 2011 at 2:49 PM, Igor Vaynberg <[email protected]>wrote: > >> here is my take on the areas that need improvement: >> >> * there is a potential to significantly reduce the size of our >> wicket-ajax.js by rebuilding it on top of a js library like jquery >> which provides all the basics such as an ajax pipeline and >> replaceOuterHtml() function. >> * currently we use inline attributes, eg adding a behavior to a >> component adds javascript in an onclick attribute. we need to switch >> to using dom events for this. this will solve the long outstanding >> problem of "cant add multiple behaviors to the same event" >> * server-side customization of callbacks is very difficult. eg it is >> not easy to add a callback variable that clientside js would pass to >> the serverside callback. this essentially requires a >> sql-injection-like attack on the callback url generated by wicket - so >> its a big hack. >> * ajax generates *a lot* of javascript in the source, making the >> document bigger. we can reduce that significantly. >> * better support for ajax channels and blocking behavior. eg right now >> its pretty hard to write an ajax button/link that blocks multiple hits >> or perhaps blocks all other ajax activity on the page. >> >> -igor >> >> >> On Mon, Sep 19, 2011 at 10:20 AM, tetsuo <[email protected]> wrote: >> > What is so broken about the current ajax in Wicket, that requires such >> > rewrite? >> > >> > >> > >> > On Mon, Sep 19, 2011 at 1:11 PM, Igor Vaynberg <[email protected] >> >wrote: >> > >> >> staged approach is fine, however its step 2 only that will cause >> >> migration headaches, so this is just delaying the inevitable... >> >> >> >> -igor >> >> >> >> >> >> On Mon, Sep 19, 2011 at 8:29 AM, Martin Grigorov <[email protected]> >> >> wrote: >> >> > Hi, >> >> > >> >> > In the recent ticket changes by Igor I mentioned few comments that >> >> > Ajax will be re-written for Wicket.next (1.6, 3.0, 6.0 - whatever we >> >> > call it). >> >> > >> >> > I want to share my experience with trying to re-vive Matej's work at >> [1], >> >> [2]. >> >> > The changes there are a bit drastic (maybe because the task hasn't >> >> > been finished and the API breaks not cleaned) and knowing how Ajax >> >> > heavy are the applications I've worked on I think it will be quite a >> >> > work to migrate the apps from 1.5 to Wicket.next. >> >> > I also tried to introduce wicket-ajax.jar with the new impl and keep >> >> > the old one for transition but that wasn't easy too. >> >> > >> >> > So I want to propose a two step approach: >> >> > 1) introduce some JavaScript library for Wicket.next and improve >> >> > wicket-xyz.js files by using it >> >> > 2) improve/reimplement Wicket Ajax for Wicket.next+1 >> >> > >> >> > >> >> > martin-g >> >> > >> >> > 1. >> >> >> http://svn.apache.org/viewvc/wicket/sandbox/knopp/experimental/wicket/src/main/java/org/apache/_wicket/ajax/ >> >> > 2. https://github.com/martin-g/wicket/tree/ajax2 >> >> > >> >> >> > >> >
