Spring-JavaScript (a submodule of Spring WebFlow) used a modular approach, in which you could (in theory, at least) provide multiple implementations of a javascript API ( http://static.springsource.org/spring-webflow/docs/2.0.x/reference/html/ch11s03.html ).
You'd import the underlying library (dojo.js), the high-level library API (spring.js), and then the implementation of the low-level API, used by the high-level library (spring-dojo.js). I say in theory because they have a Dojo implementation, but never bothered to provide other implementations ( https://jira.springsource.org/browse/SWF-1288)... Ah, one more item in the wishlist is the possibility of joining the many js/css resources in one big file. I think it's very hard/impossible to do it transparently (due the high granularity), but should be relatively easy if it required fine-tunning of the app (for example, registering all js/css resources to be joined/omitted in some application-wide setting). Tetsuo On Mon, Sep 19, 2011 at 4:03 PM, Martin Grigorov <mgrigo...@apache.org>wrote: > On Mon, Sep 19, 2011 at 8:49 PM, Igor Vaynberg <igor.vaynb...@gmail.com> > 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 <ronald.tet...@gmail.com> > 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 <igor.vaynb...@gmail.com > >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 <mgrigo...@apache.org > > > >>> 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 >
