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 > >> > > >> > > >
