Well, you can use whatever Ajax/javascript framework you want. Wicket-ajax should work with all major js frameworks. It's not really meant to be used outside wicket, as we don't guarantee api stability of wicket-ajax (but that doesn't mean you can't use it though).
We try to keep the footprint as low as possible, so that it gives you minimum overhead if you want to use a custom framework too. -Matej On 9/5/07, bmarvell <[EMAIL PROTECTED]> wrote: > > Agreed hence why I said I was coining the _business_ term. > > > Johan Compagner wrote: > > > > stupid thing is that all those slides and fades and fancy ui things are > > not > > really ajax.. > > thats just JavaScript/DHTML > > > > johan > > > > > > On 9/5/07, bmarvell <[EMAIL PROTECTED]> wrote: > >> > >> > >> Sorry if this has been asked several times but it I didn't easily find it > >> from a search. > >> > >> Fair enough about the actual "Ajax" functionality if specific code is > >> required fair enough. > >> > >> I was using the term Ajax in a very business sense ie: full stack > >> functionality; slides, fades etc. > >> > >> So for those specific issues are we to say: > >> > >> > >> http://martijndashorst.com/blog/2007/04/16/javascript-animation-libraries-compared/ > >> > >> Is the future?? > >> > >> > >> Matej Knopp-2 wrote: > >> > > >> > Hi, > >> > > >> > this question has been asked here numerous times. The thing is, there > >> > is in fact no real alternative of wicket-ajax for us. > >> > > >> > Wicket is not built about Ajax widgets.Wicket is about server-side > >> > components that can be partially updated using Ajax. That's a > >> > fundamental difference. > >> > > >> > As for the features, wicket-ajax has numerous advanced features such as > >> > - asynchronous pipeline that allows loading dependencies in > >> > asynchronous way, yet respecting the order (unlike e.g. dojo where the > >> > depending javascript are loaded using synchronous http requests which > >> > block entire browser = usability disaster) > >> > - ajax channels that allow you to stack or drop pending requests > >> > - multipart ajax response for replacing multiple components in one > >> > response, ajax header contribution processing (so that component can > >> > render header response as it would normally do, wicket transparently > >> > processes it and loads all dependencies (javascript references, > >> > stylesheets, etc) in an asynchronous way while respecting the order) > >> > - wicket-ajax.js is about 7kb compressed (with stripped down > >> > comments). As this is a general purpose ajax framework, the size > >> > matters. For sites where you using ajax only on certain places, having > >> > a 200kb javascript dependency would be quite a burden > >> > - there's more to it, the code is quite well documented, if you are > >> > interested you can dig into it, also you should search achives, this > >> > has been discussed here already. > >> > > >> > -Matej > >> > > >> > > >> > On 9/5/07, bmarvell <[EMAIL PROTECTED]> wrote: > >> >> > >> >> Hello all, > >> >> > >> >> This is my first post so please be gentle ;) > >> >> > >> >> I'm a user interface developer (no Java) working on what will > >> inevitably > >> >> be > >> >> a fairly heavy Ajax wicket project. After looking at a number of Ajax > >> >> examples and pre built widgets I have to say I'm a little puzzled! Why > >> >> does > >> >> wickets core JS framework not use one of the main JS frameworks that > >> are > >> >> available such as jQuery, Dojo or Prototype? I believe you have a hand > >> >> rolled version of mootools (although I may be wrong). Do the Wicket > >> core > >> >> team plan on supporting and enriching this hand rolled framework > >> alone? > >> >> Surely it would make more sense to choose one of the main JS > >> frameworks > >> >> that > >> >> have dedicated teams of devs supporting it? > >> >> > >> >> Also I've found that Ajax widgets in wicket seem quite "here and > >> there" > >> >> in > >> >> their implementation. Some demos use prototype, some use YUI (a > >> >> datepicker > >> >> for example). Doesnt this go against what JS frameworks are trying to > >> >> provide? Choosing a decent framework such as jQuery or Prototype will > >> >> give > >> >> the developer a solid toolkit on which they can build, so extra > >> >> components > >> >> such as datepickers or custom widgets can be applied as "Plugins". > >> >> Sticking > >> >> to one framework reduces hits to the server, bandwidth, load and > >> >> processing > >> >> times all of which imho are good things. > >> >> > >> >> My worry at the moment is that the demos in wicket are very "lets get > >> it > >> >> working on the frontend" and not "lets think about a framework and its > >> >> rich > >> >> functionality". > >> >> > >> >> SO to summarize :) are there any thoughts about using a single, > >> supported > >> >> framework in wicket and moving forward from there? > >> >> > >> >> Cheers, > >> >> > >> >> Ben > >> >> -- > >> >> View this message in context: > >> >> http://www.nabble.com/JavaScript-Frameworks-tf4383060.html#a12494810 > >> >> Sent from the Wicket - User mailing list archive at Nabble.com. > >> >> > >> >> > >> >> --------------------------------------------------------------------- > >> >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> >> For additional commands, e-mail: [EMAIL PROTECTED] > >> >> > >> >> > >> > > >> > --------------------------------------------------------------------- > >> > To unsubscribe, e-mail: [EMAIL PROTECTED] > >> > For additional commands, e-mail: [EMAIL PROTECTED] > >> > > >> > > >> > > >> > >> -- > >> View this message in context: > >> http://www.nabble.com/JavaScript-Frameworks-tf4383060.html#a12495715 > >> Sent from the Wicket - User mailing list archive at Nabble.com. > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > > > -- > View this message in context: > http://www.nabble.com/JavaScript-Frameworks-tf4383060.html#a12496187 > Sent from the Wicket - User mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
