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. >> + 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. > 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 :-) 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
