Igor, I should say that I was convinced already, by Matej's first response [1] to my original post on this thread, that this decision (not to mention Matej's expertise and hard work) will give us a robust, flexible and maintainable underlying infrastructure with no perceivable impact on the component or application developers' range of client-side library choices.
Regads - Cemal http://www.jWeekend.co.uk http://jWeekend.co.uk [ http://www.nabble.com/forum/ViewPost.jtp?post=19169614&framed=y 1 ] igor.vaynberg wrote: > > im not sure why you guys are making such a big deal out of this. we > are talking about javascript that is entirely internal to wicket. you > never see it, you never touch it. it is completely namespaced in > wicket's namespace. > > we have chosen a library that we are comfortable working with. if we > can get our stuff done faster and easier with yui then that is what we > are going to use... > > sure, we might use it to write some high level components (eg modal > window) that we ship with wicket, but those do not use any internal > api. there is absolutely nothing stopping you from writing your own > jquery-driven modal window component. > > so my question to you guys is: why does it matter to you which > javascript framework we use under the hood? > > -igor > > On Sun, Sep 28, 2008 at 7:01 PM, Jörn Zaefferer > <[EMAIL PROTECTED]> wrote: >> There is something new to consider when choosing a JavaScript library >> as Wicket's base: >> http://www.jondavis.net/blog/post/2008/09/jQuery-Has-Won-The-3-Year-Javascript-Framework-Battle-As-Far-As-Im-Concerned.aspx >> http://www.hanselman.com/blog/jQuerytoshipwithASPNETMVCandVisualStudio.aspx >> >> Jörn >> >> On Wed, Aug 27, 2008 at 1:05 AM, Matej Knopp <[EMAIL PROTECTED]> >> wrote: >>> On Wed, Aug 27, 2008 at 12:50 AM, Jörn Zaefferer >>> <[EMAIL PROTECTED]> wrote: >>>> On Tue, Aug 26, 2008 at 10:19 PM, Matej Knopp <[EMAIL PROTECTED]> >>>> wrote: >>>>> Hi, >>>>> >>>>> On Tue, Aug 26, 2008 at 9:24 PM, jWeekend >>>>> <[EMAIL PROTECTED]> wrote: >>>>>> >>>>>> Matej, >>>>>> >>>>>> What are the implications of the decision to "base Wicket Ajax Next >>>>>> Generation on YUI" in terms of choosing a Javascript library for >>>>>> future >>>>>> Wicket based web front ends? >>>>> actually, there really are none. The use of YUI will be more or less >>>>> internal to Wicket, so you can continue using jQuery, YUI2 or whatever >>>>> else you are using. Everything in Wicket (and YUI) is namespaced so >>>>> there are no conflicts. >>>> >>>> Of course there is the overhead of including two or more libraries in >>>> an application, which don't find desirable. >>> >>> Wicket uses only part of YUI, the compressed minified required YUI >>> javascript is about 20kb big. I would understand the concern if I used >>> dojo or some other behemoth with 200+ kb of compressed javascript. >>> >>>> >>>>>> + there's huge number and variety of jQuery plugins for those >>>>>> special >>>>>> occasions. >>>>> Unfortunately the quality of plugins varies. For actual wicket ajax >>>>> implementation i prefer to stick with the core thing, and that's where >>>>> YUI definitely beats jquery. I don't say that there are no plugins for >>>>> jQuery that covers YUI functionality. Question is how well are those >>>>> plugins supported and maintained. >>>> >>>> You are well on the point that the variety of plugins varies. I see it >>>> this way: jQuery core is small, very stable and the base for >>>> everything else JS-related. jQuery UI is the official project >>>> providing the same stability and quality for various high-level UI >>>> components (like dialogs) and also low-level components (like >>>> drag&drop, sortables). We'll see at least two major releases this year >>>> that add more components to the mix. Anything else that isn't covered >>>> by core or UI is almost always covered by some third-party plugin. >>>> While these plugin can be of bady quality (eg. no >>>> documentation/demos), they can still provide a good starting point, so >>>> that you don't have to start from scratch. Even if you do a full >>>> rewrite, the existing plugin can expose useful information like >>>> potential browser-bug-traps. >>> Problem is that the jQuery core doesn't cut it. And rewriting plugins >>> from scratch? Are you serious? This is exactly the reason why I >>> decided to use YUI. The stuff that I need is there, it is supported >>> and maintained. >>>> >>>>> Anyway, as I say, this doesn't make any implication to Wicket users or >>>>> 3rd party components. The reason why wicket ajax is based on another >>>>> framework is to get rid of most of the low level browser specific code >>>>> we have currently so that I wouldn't have to maintain it :) >>>> >>>> Whatever the framework, I think its a good idea to start with >>>> something well supported and tested. Thats why I use Wicket, though >>>> I'd like it even more with jQuery as the base framework :-) >>> >>> At this point, I really don't see any advantage that YUI would give me >>> over jQuery. >>> Also it is possible that InMethod grid will be part of Wicket 1.5 >>> extensions which is another point for using YUI. Rewriting the grid >>> with jquery would be a huge pain. >>> >>> -Matej >>> >>>> >>>> Jörn >>>> >>>> PS: Comet support is a nice to have, but I think there a way more >>>> important things for core than that, eg. annotation-based validation >>>> >>> >>> --------------------------------------------------------------------- >>> 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/%22WANG%E2%80%93Wicket-Ajax-Next-Generation%E2%80%93being-based-on-YUI%22-%28MD%29-tp19168620p19720842.html Sent from the Wicket - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
