Sorry, Again mine is coming from a very front end perspective ie writing JS in a progressive enhancement style.
Your pseudo code looks like the other end of the spectrum ie java code My main point over this thread was to also appreciate that while wicket is designed for java devs it needs to have JS framework code that can be used by UI developers. Hence why I believe having the ability to write things in a front end way is a GOOD thing. Nino Saturnino Martinez Vazquez Wael wrote: > > hmm I'll have to take a deeper look into this. > > The main idea about the input events are that you should be able to just > add events of any sort (mouse, key, time?) to anycomponent that will > either trigger that component or another, this means triggering from > client to server. No real work has been done on the input events project > other that the project are setup on the stuff svn, also some base > infrastructure has been done. > > pseudo code example: > > form myform; > > label.add(new Event(Events.keypressed(a),Event.keydown, myform)); > > above should trigger myform when a are pressed and label has focus. > > disclaimer : this might be bad example:) > > regards Nino > > bmarvell wrote: >> 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] >>> >>> >>> >>> >> >> > > --------------------------------------------------------------------- > 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#a12496854 Sent from the Wicket - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
