On Mon, Sep 19, 2011 at 8: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. I also think that JQuery will be the best to pick at the moment, but seeing what happened with Tapestry choice to use Prototype and their efforts to escape from it now. Also following Node.js trends (see Ender with its Jeesh (Bonzo, Bean, Qwery, ...), see CoffeeScript, Underscore, all these specialized CommonJS/AMD modules) I still think that picking any JS library will make some developers life harder. For example if my application is based on Dojo/ExtJS/... choosing JQuery will just add more some more bytes to my response ... That's why I think making it with adapter with default impl based on JQuery will be the best. This way Dojo users can implement the adapter and be happy. Check https://github.com/balupton/History.js to see what I mean. > * 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" I think adding multiple behaviors will be anti-pattern. This way the user will be able to add several onclick handlers and thus do several Ajax requests and this will make the processing slower, especially if they are queued. It will be better to have one event handler and split the work on the server side. > * 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 >>> > >>> >> >
-- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com
