I personally think a CSS DOM traversal/manipulation model that can tie to events elegantly is what's needed.
i.e: http://jquery.com http://bennolan.com/behaviour/ Being able to say: $("#somthing li").click(..... Is so much easier to code and read than: document.getElementById("something").getElementsByTagName("li").......... Nino Saturnino Martinez Vazquez Wael wrote: > > on the Events part I might aswell go on with the input events contrib... > As this now has been up a lot of times one the mailing list.. > > I might seem to find some time to do it.. > > But it would be really nice to see what people would like of features > from it? > > regards Nino > > bmarvell wrote: >> Right then so for completeness: >> >> * Ajax Calls [In house] >> * Animation [animator.js] >> * Dom manipulation and traversal (CSS style for this is becoming highly >> favourable) [??] >> * Events [??] >> >> Has any of this been addressed or considered yet? >> >> I'm just coming in from the point of a front end developer and trying to >> identify whats either missing or I cant find :confused: >> >> >> >> >> Gerolf Seitz wrote: >> >>>> So for those specific issues are we to say: >>>> >>>> >>>> http://martijndashorst.com/blog/2007/04/16/javascript-animation-libraries-compared/ >>>> >>>> Is the future?? >>>> >>> in this case, take a look at >>> http://wicketstuff.org/confluence/display/STUFFWIKI/wicketstuff-animator >>> ;) >>> >>> gerolf >>> >>> 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] >>>> >>>> >>>> >>> >> >> > > --------------------------------------------------------------------- > 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#a12496447 Sent from the Wicket - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
