Sure i wanna do "real programming" in javascript. My issue was, the back end devs here can tap away writing wicket but it wont cover 100% of the interactions that are needed on the front end. So I hoped that if wicked used a preferred JS framework for some of its widgets I could save alot of overhead and go with that on the _other_ frontend interactions i have to deal with.
Anyways, thanks for the help people. Johan Compagner wrote: > > ahh so you want to do real programming in the javascript? > So attaching purely in client side javascript events and those events call > the server? > > Thats not how wicket works, in wicket you normally don't program > javascript > you get it pushed > and the events get attached by the serverside. > > johan > > > On 9/5/07, bmarvell <[EMAIL PROTECTED]> wrote: >> >> >> 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] >> >> > > -- View this message in context: http://www.nabble.com/JavaScript-Frameworks-tf4383060.html#a12518272 Sent from the Wicket - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
