Hi Korbinian, On Tue, Sep 20, 2011 at 10:48 AM, Korbinian Bachl - privat <[email protected]> wrote: > Well, I think there is consent that we can say current wicket ajax is quite > broken and a big pain in everyday usage. Really? Is that broken ? Neither mailing lists questions nor tickets prove that statement. > > The current ajax means loads of code in java for even trivial things. > Triple-checking that a component knows its ajax and so on. So even *if* it > will break api in future, I don't see a way around this! > > Do we want all those AjaxRequestTargets, .setOutput******(boolean) and more > of this even here in some years? Don't think so. What do you suggest ? The only option that I see as automatic is to set it for each and every component, no matter whether it will be ever updated with Ajax or not. > > The other question is now what to do (from a higher perspective): > > 1st: do it on own > 2nd: use somebody else's work > > I would go for 2 and most specific go for a complete jQuery based wicket. This is clear. > Reasons are: > > - jQuery is well designed, upgrade paths are good documented > > - jQuery is *known* to already many many people, there are a ton of > documentation out there - from books to DVD's! > > - jQuery is actively developed by quite many people, just see how many are > taking care for just (!) a JavaScript library: http://jquery.org/team/ and > then compare the manpower to wicket itself that has much more to be taken > care of > > - jQuery *is* browser safe! I cant stop counting the times when I upgraded a > browser and suddenly wicket Ajax stopped working, currently Opera 11.51 just > killed one of my modal windows - at version 10.50 it worked... staying up to > date now would only mean to make sure jQuery is up-to-date > > - jQuery gives you hooks to interact with and provides some sort of > layering, but please don't go the spring way (nobody needs *another* own > breed java-script layer that then won't be really worked on and/ or cared > for "up-to-dateness") > > and final > > -jQuery will save the wicket dev's much work in the future!
Not sure whether you invested some of your time to see what is needed by wicket-ajax.js and what JQuery (or other major JS libs) offers but my investigation showed that none of them solves the problem with replaceOuterHtml() out of the box. So we will have to translate our code in JQuery parlance but still will have to keep the "hacks". > > > my 2c > > > > Am 19.09.11 17:29, schrieb Martin Grigorov: >> >> 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
