Re: WANG–Wicket Ajax Next Generation –being based on YUI (MD)
Hi Matej I was just thinking if WANG Wicket Ajax comes loosely coupled to the js lib? If it does, then people could then implement their own js bridge to what ever js framework they like... Im just thinking aloud here... Btw, I don't care which js lib you are gonna use as long as it's the best for wicket and you. Matej Knopp wrote: Okay, let's keep this focused. Here is my experimental branch. http://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/ There is new Ajax implementation here: http://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/wicket/src/main/java/org/apache/_wicket/ajax/js/wicket-ajax-ng.js and the main AjaxBehavior here: http://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/wicket/src/main/java/org/apache/_wicket/ajax/AjaxBehavior.java What I'd like to hear is what exactly is wrong with it and how using jQuery (or any other framework for that matter) could improve things. -Matej On Mon, Sep 29, 2008 at 11:45 PM, Martijn Dashorst [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 11:13 PM, Jörn Zaefferer [EMAIL PROTECTED] wrote: PS: I'm currently sitting on a panel with PPK and guys from Prototype, Dojo, YUI and jQuery. One question was: What library would you recommend but your own?. Two of the three non-jQuery guys recommened jQuery So you're saying that 75% of the leading JS framework community think jquery is second best. Please keep the jquery marketing BS and fanboyism to the jquery forums. It serves nobody any good. In fact it makes me cringe and want to -1 any and all votes for adopting anything near jquery. Martijn - 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] -- -Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WANG–Wicket Ajax Next Generation–being based on YUI (MD)
ExtJS actually tried implementing bridges to other libraries when they tried to get independent of YUI. The ended with rolling their own and removing all bridges. Unfortunately its still a bloated intertangled web of dependencies, with over 200k for just some basics... Jörn On Tue, Sep 30, 2008 at 10:03 AM, Nino Saturnino Martinez Vazquez Wael [EMAIL PROTECTED] wrote: Hi Matej I was just thinking if WANG Wicket Ajax comes loosely coupled to the js lib? If it does, then people could then implement their own js bridge to what ever js framework they like... Im just thinking aloud here... Btw, I don't care which js lib you are gonna use as long as it's the best for wicket and you. Matej Knopp wrote: Okay, let's keep this focused. Here is my experimental branch. http://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/ There is new Ajax implementation here: http://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/wicket/src/main/java/org/apache/_wicket/ajax/js/wicket-ajax-ng.js and the main AjaxBehavior here: http://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/wicket/src/main/java/org/apache/_wicket/ajax/AjaxBehavior.java What I'd like to hear is what exactly is wrong with it and how using jQuery (or any other framework for that matter) could improve things. -Matej On Mon, Sep 29, 2008 at 11:45 PM, Martijn Dashorst [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 11:13 PM, Jörn Zaefferer [EMAIL PROTECTED] wrote: PS: I'm currently sitting on a panel with PPK and guys from Prototype, Dojo, YUI and jQuery. One question was: What library would you recommend but your own?. Two of the three non-jQuery guys recommened jQuery So you're saying that 75% of the leading JS framework community think jquery is second best. Please keep the jquery marketing BS and fanboyism to the jquery forums. It serves nobody any good. In fact it makes me cringe and want to -1 any and all votes for adopting anything near jquery. Martijn - 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] -- -Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WANG–Wicket Ajax Next Generation– being based on YUI (MD)
From checking wicket ajax and wicket event as is now, it's not that many lines of code. I guess you should just be able to drop in your own version of them I guess.. But if people are never to do the bridgin then it's just a vaste of time. Jörn Zaefferer wrote: ExtJS actually tried implementing bridges to other libraries when they tried to get independent of YUI. The ended with rolling their own and removing all bridges. Unfortunately its still a bloated intertangled web of dependencies, with over 200k for just some basics... Jörn On Tue, Sep 30, 2008 at 10:03 AM, Nino Saturnino Martinez Vazquez Wael [EMAIL PROTECTED] wrote: Hi Matej I was just thinking if WANG Wicket Ajax comes loosely coupled to the js lib? If it does, then people could then implement their own js bridge to what ever js framework they like... Im just thinking aloud here... Btw, I don't care which js lib you are gonna use as long as it's the best for wicket and you. Matej Knopp wrote: Okay, let's keep this focused. Here is my experimental branch. http://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/ There is new Ajax implementation here: http://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/wicket/src/main/java/org/apache/_wicket/ajax/js/wicket-ajax-ng.js and the main AjaxBehavior here: http://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/wicket/src/main/java/org/apache/_wicket/ajax/AjaxBehavior.java What I'd like to hear is what exactly is wrong with it and how using jQuery (or any other framework for that matter) could improve things. -Matej On Mon, Sep 29, 2008 at 11:45 PM, Martijn Dashorst [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 11:13 PM, Jörn Zaefferer [EMAIL PROTECTED] wrote: PS: I'm currently sitting on a panel with PPK and guys from Prototype, Dojo, YUI and jQuery. One question was: What library would you recommend but your own?. Two of the three non-jQuery guys recommened jQuery So you're saying that 75% of the leading JS framework community think jquery is second best. Please keep the jquery marketing BS and fanboyism to the jquery forums. It serves nobody any good. In fact it makes me cringe and want to -1 any and all votes for adopting anything near jquery. Martijn - 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] -- -Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WANG–Wicket Ajax Next Generation–being based on YUI (MD)
Thanks for the response.
On Tue, Sep 30, 2008 at 5:11 AM, Jörn Zaefferer
[EMAIL PROTECTED] wrote:
I'll go through a few things in the wicket-ajax-ng.js file, to give an
idea how that could look like when putting it on top of jQuery. I skip
all stuff where I can't guess while scanning the code whats its
supposed to do.
W.$ looks like it selects one or more elements by id. Selecting is
completely encapsulated in the jQuery-function, so you would change
the usage a bit:
W.$(myID) == $(#myID).get(0)
W.$(id1, id2) == $(#id1, #id2).get()
well, since we are not using any selector but # here, this is more
like a cosmetic thing.
Usually you won't need to reference the DOM elements, so you could
remove the get(0) and get() calls.
W.$$ would just use:
if ($(#id).size() ) {
// element exists
}
That's not entirely corrent i believe. If you pass element instance to
W.$$ it checks if the element is part of active document. That's very
important for wicket to determine if the queued ajax request is still
valid.
copyArray can be replaced with jQuery.makeArray
(http://dev.jquery.com/browser/trunk/jquery/src/core.js#L1130), which
is heavily optimized and takes stuff like passing window as an
argument into account.
We only copy small arrays, the performance of array copy has never
bothered me much :)
iterateArray could be replaced with jQuery.each, though the symantics
are slightly different. jQuery.each iterates over both objects and
arrays.
The GarbageCollector wouldn't be necessary: jQuery cleans up all event
listeneres when removing elements from the DOM. You don't have to
bother with that at all.
Well, this is a rather unfortunate thing with YUI. If you bind event
to element and then remove the element, yui only seem to release the
element when window is being unloaded, which causes certain problems
in IE. The memory consumption grows over time if you stay on single
page, though it's not really a leak because the memory gets reclaimed
on page reload. That's why i built the garbage collector that goes
over elements and checks if they are still in the document.
So I'm a bit curious here, how does jQuery know that element has been
removed from document? And how does it know that I don't want to use
it anymore? Or are all the events released when I use jQuery API to
remove element from document? But what if i keep reference to that
element myself (after removing it from the document) and I don't want
the events to be removed (this part isn't really solved with current
version of the Garbage Collectior either).
Like I mentioned earlier, replaceOuterHtmlXXX shouldn't be necessary
at all, jQuery handles that automatically for all DOM manipulation
methods.
That's a good news if the method really works as advertised (plus has
decent performance for replacing large chunks of markup, which I'd
have to test first though).
mapToUrlParameters would be handled by jQuery.param. Though usually
when using jQuery's ajax methods, you don't have to worry about that.
For example, to post some parameters to the server, you'd just use
jQuery.ajax with the data option:
Sure, as long as jQuery allows me to make distinction between GET and
POST parameters. If it doesn't, I'd still have to encode the
parameters for query string myself.
$.ajax({
url: ...,
method: post
data: {
key1: value1,
key2: value2
}
});
And so far I've covered only jQuery core functionality. What do you think?
Well, so far the element replacement method would be a benefit if it
really works like Wicket.replaceOuterHTML does. As well as no
leaking when removing elements with attached events from document,
if it, indeed, works :)
One thing that has crossed my mind too. YUI contains API for getting
absolute coordinates of element as well as settings absolute
coordinates to element (it takes care of setting proper position
attributes, etc.). Last time I checked this was only available as a
separate plugin for jQuery. This is a functionality that is really
useful, if not for the base wicket API, then for the extentions. Is
this part of jQuery core, or will it be in future?
-Matej
Jörn
On Mon, Sep 29, 2008 at 11:50 PM, Matej Knopp [EMAIL PROTECTED] wrote:
Okay, let's keep this focused.
Here is my experimental branch.
http://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/
There is new Ajax implementation here:
http://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/wicket/src/main/java/org/apache/_wicket/ajax/js/wicket-ajax-ng.js
and the main AjaxBehavior here:
http://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/wicket/src/main/java/org/apache/_wicket/ajax/AjaxBehavior.java
What I'd like to hear is what exactly is wrong with it and how using
jQuery (or any other framework for that matter) could improve things.
-Matej
On Mon, Sep 29, 2008 at 11:45 PM, Martijn Dashorst
[EMAIL PROTECTED] wrote:
On Mon, Sep 29, 2008 at 11:13 PM, Jörn Zaefferer
[EMAIL
Re: WANG–Wicket Ajax Next Generation–being based on YUI (MD)
On Tue, Sep 30, 2008 at 3:27 PM, Matej Knopp [EMAIL PROTECTED] wrote: One thing that has crossed my mind too. YUI contains API for getting absolute coordinates of element as well as settings absolute coordinates to element (it takes care of setting proper position attributes, etc.). Last time I checked this was only available as a separate plugin for jQuery. This is a functionality that is really useful, if not for the base wicket API, then for the extentions. Is this part of jQuery core, or will it be in future? I think the Dimensions plugin is now merged into jquery as of 1.2.6. Frank
Re: WANG–Wicket Ajax Next Generation –being based on YUI (MD)
Ok I hear you. But could'nt be something as simple as being able to roll your own js instead of the default wicket js ones? I mean just define the functions requried in the wicket name space.. Again im just tossing out ideas here.. And it might just be possible as everything are now.. Matej Knopp wrote: I'm not keen on this at all. It would require me to specify stable API, specify proper contracts and stick to it. Wicket ajax should be treated as something opaque. Plus it would be hell to support. With every problem I'd have to investigate what implementation user uses, what bridge and if the problem is Wicket-Ajax related at all. -Matej On Tue, Sep 30, 2008 at 10:03 AM, Nino Saturnino Martinez Vazquez Wael [EMAIL PROTECTED] wrote: Hi Matej I was just thinking if WANG Wicket Ajax comes loosely coupled to the js lib? If it does, then people could then implement their own js bridge to what ever js framework they like... Im just thinking aloud here... Btw, I don't care which js lib you are gonna use as long as it's the best for wicket and you. Matej Knopp wrote: Okay, let's keep this focused. Here is my experimental branch. http://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/ There is new Ajax implementation here: http://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/wicket/src/main/java/org/apache/_wicket/ajax/js/wicket-ajax-ng.js and the main AjaxBehavior here: http://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/wicket/src/main/java/org/apache/_wicket/ajax/AjaxBehavior.java What I'd like to hear is what exactly is wrong with it and how using jQuery (or any other framework for that matter) could improve things. -Matej On Mon, Sep 29, 2008 at 11:45 PM, Martijn Dashorst [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 11:13 PM, Jörn Zaefferer [EMAIL PROTECTED] wrote: PS: I'm currently sitting on a panel with PPK and guys from Prototype, Dojo, YUI and jQuery. One question was: What library would you recommend but your own?. Two of the three non-jQuery guys recommened jQuery So you're saying that 75% of the leading JS framework community think jquery is second best. Please keep the jquery marketing BS and fanboyism to the jquery forums. It serves nobody any good. In fact it makes me cringe and want to -1 any and all votes for adopting anything near jquery. Martijn - 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] -- -Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - 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] -- -Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WANG–Wicket Ajax Next Generation–being based on YUI (MD)
About removing events when removing elements: jQuery always removes
events when removing an element from the DOM. If you want to actually
move an element to insert it somewhere else, you can do that just as
well, you just may not use it with remove. Eg.
$(element).insertAfter(otherElement); will move element somewhere
else, keeping all events intact.
The replaceOuterHTML-replacement should be already heavily optimized,
though thats actually something that should work much better in jQuery
1.3, which is planned for fall 2008.
About get/post: True, if you use method: post, all data-parameters
are posted. Though you can still just use $.param to seriliaze the
get-parameters and append it manually to the URL.
$.ajax({
url: ...? + $.param(getParams),
data: postParams
});
Offset and position computations were part of the dimensions plugin,
which is now merged into jQuery core, so that is readily available and
official.
Jörn
On Tue, Sep 30, 2008 at 3:27 PM, Matej Knopp [EMAIL PROTECTED] wrote:
Thanks for the response.
On Tue, Sep 30, 2008 at 5:11 AM, Jörn Zaefferer
[EMAIL PROTECTED] wrote:
I'll go through a few things in the wicket-ajax-ng.js file, to give an
idea how that could look like when putting it on top of jQuery. I skip
all stuff where I can't guess while scanning the code whats its
supposed to do.
W.$ looks like it selects one or more elements by id. Selecting is
completely encapsulated in the jQuery-function, so you would change
the usage a bit:
W.$(myID) == $(#myID).get(0)
W.$(id1, id2) == $(#id1, #id2).get()
well, since we are not using any selector but # here, this is more
like a cosmetic thing.
Usually you won't need to reference the DOM elements, so you could
remove the get(0) and get() calls.
W.$$ would just use:
if ($(#id).size() ) {
// element exists
}
That's not entirely corrent i believe. If you pass element instance to
W.$$ it checks if the element is part of active document. That's very
important for wicket to determine if the queued ajax request is still
valid.
copyArray can be replaced with jQuery.makeArray
(http://dev.jquery.com/browser/trunk/jquery/src/core.js#L1130), which
is heavily optimized and takes stuff like passing window as an
argument into account.
We only copy small arrays, the performance of array copy has never
bothered me much :)
iterateArray could be replaced with jQuery.each, though the symantics
are slightly different. jQuery.each iterates over both objects and
arrays.
The GarbageCollector wouldn't be necessary: jQuery cleans up all event
listeneres when removing elements from the DOM. You don't have to
bother with that at all.
Well, this is a rather unfortunate thing with YUI. If you bind event
to element and then remove the element, yui only seem to release the
element when window is being unloaded, which causes certain problems
in IE. The memory consumption grows over time if you stay on single
page, though it's not really a leak because the memory gets reclaimed
on page reload. That's why i built the garbage collector that goes
over elements and checks if they are still in the document.
So I'm a bit curious here, how does jQuery know that element has been
removed from document? And how does it know that I don't want to use
it anymore? Or are all the events released when I use jQuery API to
remove element from document? But what if i keep reference to that
element myself (after removing it from the document) and I don't want
the events to be removed (this part isn't really solved with current
version of the Garbage Collectior either).
Like I mentioned earlier, replaceOuterHtmlXXX shouldn't be necessary
at all, jQuery handles that automatically for all DOM manipulation
methods.
That's a good news if the method really works as advertised (plus has
decent performance for replacing large chunks of markup, which I'd
have to test first though).
mapToUrlParameters would be handled by jQuery.param. Though usually
when using jQuery's ajax methods, you don't have to worry about that.
For example, to post some parameters to the server, you'd just use
jQuery.ajax with the data option:
Sure, as long as jQuery allows me to make distinction between GET and
POST parameters. If it doesn't, I'd still have to encode the
parameters for query string myself.
$.ajax({
url: ...,
method: post
data: {
key1: value1,
key2: value2
}
});
And so far I've covered only jQuery core functionality. What do you think?
Well, so far the element replacement method would be a benefit if it
really works like Wicket.replaceOuterHTML does. As well as no
leaking when removing elements with attached events from document,
if it, indeed, works :)
One thing that has crossed my mind too. YUI contains API for getting
absolute coordinates of element as well as settings absolute
coordinates to element (it takes care of setting proper position
attributes, etc.). Last time I checked this was only
Re: WANG–Wicket Ajax Next Generation–being based on YUI (MD)
Are you really that surprised that Microsoft is not shipping YUI after the failed attempts to take over Yahoo? :) Seriously, there are technical reasons why I considered to use YUI, not political. Just because some companies use jQuery it doesn't mean Wicket should use it. Say most of the companies use JSF, does it mean we should? As I said, I really like the way YUI api is designed. Also there are things in YUI core that are only available as jQuery plugins. The plugins have different lifecycle than the core and are mantained differently. Also keep in mind that the javascript Wicket-Ajax uses is internal to Wicket. Let me give you an example where I find YUI (3) api more elegant. That's just one of many things and it is of course my personal opinion. If i want to unbind event in jQuery, i need to remember event name and the exact handler instance. For YUI, i get event handler on bind that i can just call detach on and the event is unbound. var h = Y.on(click, handleClick, element); h.detach(); Of course it is possible to mock the behavior with jQuery, but that's not really the point, is it? Another this is functionality provided in core. YUI can handle multipart Ajax uploads (well, it can't do that in 3.0 yet, but it's very likely it will be as it was supported in 2.x). For jQuery, i need to use a plugin for it. The reason why I feel so uneasy about plugins is that I've tried some. And the quality really varies. I think selectors might be the part where jQuery really shines. But that's the part not needed by Wicket at all. Plus YUI has selectors too (although maybe not that fast - I don't know, haven't profiled them). Also the new YUI3 node API resembles jQuery chaining API for those who like it. -Matej On Mon, Sep 29, 2008 at 4:01 AM, 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 dragdrop, 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
Re: WANG–Wicket Ajax Next Generation–being based on YUI (MD)
It would be a big plus for me if Wicket would adopt jQuery. Drupal does that, and anyone writing a Drupal module can rely on the fact that jQuery is available. Same for Wordpress, where plugin authors can rely on the availability of jQuery. And not having to load more than one library, internal or not, is a good thing performance-wise. In response to your examples: Unbinding only particular event handlers without having a reference to the handler function can be achieved with namespaces: $(element).bind(click.somethingUnique, handleClick); $(element).unbind(click.somethingUnique); That way you don't have to keep a reference at all, while its possible to group multiple events into one namespace. This is now heavily used by most jQuery UI components when destroyed, to clean up their own event handlers without affecting any other. Multiple file upload we'll eventually have as part of jQuery UI. That would then be the same level of official and supported component that YUI provides. The descision to add new components is partly community-driven. So if you think multipart ajax uploads should be added, just ask for it. About selectors: John Resig is currently working on a new selector engine that likely outperformances any other selector engine available so far. Its developed as a standalone library, so its likely that MochKit and Prototype will use it, too. jQuery 1.3. will also provide heavy performance improvements for DOM manipulations, which I'm very exited about as that is usually where most time is spent. Its easy to avoid running certain selectors too often, but its hard to optimize DOM manipulation in clientcode. Anyway, thanks for taking the time to discuss this again. Jörn On Mon, Sep 29, 2008 at 12:54 PM, Matej Knopp [EMAIL PROTECTED] wrote: Are you really that surprised that Microsoft is not shipping YUI after the failed attempts to take over Yahoo? :) Seriously, there are technical reasons why I considered to use YUI, not political. Just because some companies use jQuery it doesn't mean Wicket should use it. Say most of the companies use JSF, does it mean we should? As I said, I really like the way YUI api is designed. Also there are things in YUI core that are only available as jQuery plugins. The plugins have different lifecycle than the core and are mantained differently. Also keep in mind that the javascript Wicket-Ajax uses is internal to Wicket. Let me give you an example where I find YUI (3) api more elegant. That's just one of many things and it is of course my personal opinion. If i want to unbind event in jQuery, i need to remember event name and the exact handler instance. For YUI, i get event handler on bind that i can just call detach on and the event is unbound. var h = Y.on(click, handleClick, element); h.detach(); Of course it is possible to mock the behavior with jQuery, but that's not really the point, is it? Another this is functionality provided in core. YUI can handle multipart Ajax uploads (well, it can't do that in 3.0 yet, but it's very likely it will be as it was supported in 2.x). For jQuery, i need to use a plugin for it. The reason why I feel so uneasy about plugins is that I've tried some. And the quality really varies. I think selectors might be the part where jQuery really shines. But that's the part not needed by Wicket at all. Plus YUI has selectors too (although maybe not that fast - I don't know, haven't profiled them). Also the new YUI3 node API resembles jQuery chaining API for those who like it. -Matej On Mon, Sep 29, 2008 at 4:01 AM, 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
Re: WANG–Wicket Ajax Next Generation–being based on YUI (MD)
On Mon, Sep 29, 2008 at 1:18 PM, Jörn Zaefferer [EMAIL PROTECTED] wrote: It would be a big plus for me if Wicket would adopt jQuery. Drupal does that, and anyone writing a Drupal module can rely on the fact that jQuery is available. Same for Wordpress, where plugin authors can rely on the availability of jQuery. And not having to load more than one library, internal or not, is a good thing performance-wise. In response to your examples: Unbinding only particular event handlers without having a reference to the handler function can be achieved with namespaces: $(element).bind(click.somethingUnique, handleClick); $(element).unbind(click.somethingUnique); But that's not quite the same. This requires me to use generate and keep a unique string. Anyway, this is a cosmetic issue only. That way you don't have to keep a reference at all, while its possible to group multiple events into one namespace. This is now heavily used by most jQuery UI components when destroyed, to clean up their own event handlers without affecting any other. Multiple file upload we'll eventually have as part of jQuery UI. That would then be the same level of official and supported component that YUI provides. The descision to add new components is partly community-driven. So if you think multipart ajax uploads should be added, just ask for it. This is not about multiple file upload. We already have such component in Wicket. This is about support for input type=file on ajax uploads - just use hidden frame instead of xml http request. About selectors: John Resig is currently working on a new selector engine that likely outperformances any other selector engine available so far. Its developed as a standalone library, so its likely that MochKit and Prototype will use it, too. That sure is nice, but the selectors are not used in Wicket core at all. jQuery 1.3. will also provide heavy performance improvements for DOM manipulations, which I'm very exited about as that is usually where most time is spent. Its easy to avoid running certain selectors too often, but its hard to optimize DOM manipulation in clientcode. While we at this, I'd like to ask. Significant part of Wicket ajax is Wicket.replaceOuterHtml method. This was really a major pain to implement and stabilize. What it does is basically a replaceOuterHTML call for all browser but it works in totally cross browser consistent way. I.e. it allows table rows, cells etc replaced in internet explorer and it also executes embedded script tags on browsers that would normally not do that (basically all except for Firefox). So my question is, just out of curiosity, is there/will there be similar functionality provided by jQuery? Anyway, thanks for taking the time to discuss this again. Sure. Keep in mind that the decision is not carved to stone. I'm open to argument, but I'm really interested in technical aspect. Having Microsoft will use jQuery is not really a valid argument to me :) -Matej Jörn On Mon, Sep 29, 2008 at 12:54 PM, Matej Knopp [EMAIL PROTECTED] wrote: Are you really that surprised that Microsoft is not shipping YUI after the failed attempts to take over Yahoo? :) Seriously, there are technical reasons why I considered to use YUI, not political. Just because some companies use jQuery it doesn't mean Wicket should use it. Say most of the companies use JSF, does it mean we should? As I said, I really like the way YUI api is designed. Also there are things in YUI core that are only available as jQuery plugins. The plugins have different lifecycle than the core and are mantained differently. Also keep in mind that the javascript Wicket-Ajax uses is internal to Wicket. Let me give you an example where I find YUI (3) api more elegant. That's just one of many things and it is of course my personal opinion. If i want to unbind event in jQuery, i need to remember event name and the exact handler instance. For YUI, i get event handler on bind that i can just call detach on and the event is unbound. var h = Y.on(click, handleClick, element); h.detach(); Of course it is possible to mock the behavior with jQuery, but that's not really the point, is it? Another this is functionality provided in core. YUI can handle multipart Ajax uploads (well, it can't do that in 3.0 yet, but it's very likely it will be as it was supported in 2.x). For jQuery, i need to use a plugin for it. The reason why I feel so uneasy about plugins is that I've tried some. And the quality really varies. I think selectors might be the part where jQuery really shines. But that's the part not needed by Wicket at all. Plus YUI has selectors too (although maybe not that fast - I don't know, haven't profiled them). Also the new YUI3 node API resembles jQuery chaining API for those who like it. -Matej On Mon, Sep 29, 2008 at 4:01 AM, Jörn Zaefferer [EMAIL PROTECTED] wrote: There is something new to consider when choosing a JavaScript
Re: WANG–Wicket Ajax Next Generation–being based on YUI (MD)
I guess I didn't quite get the file upload example in the first place. Uploading via iframe is supported by jQuery's form plugin, which is one of the best plugins we have. We plan to add it, together with other related plugins, to jQuery UI forms (or something like that). About selectors: jQuery promotes progressive enhancement a lot, and selectors are essential for that. One example for that is that we avoid inline onclick=.. and similar stuff. I'm not sure how that would be handled by Wicket, and if using jQuery would open ways to handle things differently. I can't give you too many details on replaceOuterHtml, though that sounds like I can easily get more info on. Currently jQuery does a lot of work cleaning html input that is appended into the DOM, which seems to be basically the same usecase here. Also executing script-tags is something we cover. Could you give me an example how exactly replaceOuterHTML is currently used? About the Microsoft argument: True, from a technical perspective that doesn't matter. But its an important political aspect: I already read a few comments from people that couldn't use jQuery due to a general no open-source policy - but now that Microsoft, that had exactly that policy, is changed theirs, it could enable others to adopt it, too. Jörn PS: I'm currently sitting on a panel with PPK and guys from Prototype, Dojo, YUI and jQuery. One question was: What library would you recommend but your own?. Two of the three non-jQuery guys recommened jQuery On Mon, Sep 29, 2008 at 1:41 PM, Matej Knopp [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 1:18 PM, Jörn Zaefferer [EMAIL PROTECTED] wrote: It would be a big plus for me if Wicket would adopt jQuery. Drupal does that, and anyone writing a Drupal module can rely on the fact that jQuery is available. Same for Wordpress, where plugin authors can rely on the availability of jQuery. And not having to load more than one library, internal or not, is a good thing performance-wise. In response to your examples: Unbinding only particular event handlers without having a reference to the handler function can be achieved with namespaces: $(element).bind(click.somethingUnique, handleClick); $(element).unbind(click.somethingUnique); But that's not quite the same. This requires me to use generate and keep a unique string. Anyway, this is a cosmetic issue only. That way you don't have to keep a reference at all, while its possible to group multiple events into one namespace. This is now heavily used by most jQuery UI components when destroyed, to clean up their own event handlers without affecting any other. Multiple file upload we'll eventually have as part of jQuery UI. That would then be the same level of official and supported component that YUI provides. The descision to add new components is partly community-driven. So if you think multipart ajax uploads should be added, just ask for it. This is not about multiple file upload. We already have such component in Wicket. This is about support for input type=file on ajax uploads - just use hidden frame instead of xml http request. About selectors: John Resig is currently working on a new selector engine that likely outperformances any other selector engine available so far. Its developed as a standalone library, so its likely that MochKit and Prototype will use it, too. That sure is nice, but the selectors are not used in Wicket core at all. jQuery 1.3. will also provide heavy performance improvements for DOM manipulations, which I'm very exited about as that is usually where most time is spent. Its easy to avoid running certain selectors too often, but its hard to optimize DOM manipulation in clientcode. While we at this, I'd like to ask. Significant part of Wicket ajax is Wicket.replaceOuterHtml method. This was really a major pain to implement and stabilize. What it does is basically a replaceOuterHTML call for all browser but it works in totally cross browser consistent way. I.e. it allows table rows, cells etc replaced in internet explorer and it also executes embedded script tags on browsers that would normally not do that (basically all except for Firefox). So my question is, just out of curiosity, is there/will there be similar functionality provided by jQuery? Anyway, thanks for taking the time to discuss this again. Sure. Keep in mind that the decision is not carved to stone. I'm open to argument, but I'm really interested in technical aspect. Having Microsoft will use jQuery is not really a valid argument to me :) -Matej Jörn On Mon, Sep 29, 2008 at 12:54 PM, Matej Knopp [EMAIL PROTECTED] wrote: Are you really that surprised that Microsoft is not shipping YUI after the failed attempts to take over Yahoo? :) Seriously, there are technical reasons why I considered to use YUI, not political. Just because some companies use jQuery it doesn't mean Wicket should use it. Say most of the companies use JSF, does
Re: WANG–Wicket Ajax Next Generation–being based on YUI (MD)
On Mon, Sep 29, 2008 at 11:13 PM, Jörn Zaefferer [EMAIL PROTECTED] wrote: I guess I didn't quite get the file upload example in the first place. Uploading via iframe is supported by jQuery's form plugin, which is one of the best plugins we have. We plan to add it, together with other related plugins, to jQuery UI forms (or something like that). Well, that's what I'm talking about. It's a separate plugin. I don't know how good the plugin is. How actively it is mantained. Can I rely on it? Those are the questions I do not need to ask when dealing with YUI. About selectors: jQuery promotes progressive enhancement a lot, and selectors are essential for that. One example for that is that we avoid inline onclick=.. and similar stuff. I'm not sure how that would be handled by Wicket, and if using jQuery would open ways to handle things differently. In wicket 1.5 there won't be any inline handlers in the markup. All events will be attached separately. I can't give you too many details on replaceOuterHtml, though that sounds like I can easily get more info on. Currently jQuery does a lot of work cleaning html input that is appended into the DOM, which seems to be basically the same usecase here. Also executing script-tags is something we cover. Could you give me an example how exactly replaceOuterHTML is currently used? It is used every time Ajax request replaces component on page. Wicket.replaceOuterHTML(element, newmarkup); It replaces the element (the tag itself) with the new markup. But it takes care of some things such as when the element is a table row or cell, or if there are script tag embedded in the markup. About the Microsoft argument: True, from a technical perspective that doesn't matter. But its an important political aspect: I already read a few comments from people that couldn't use jQuery due to a general no open-source policy - but now that Microsoft, that had exactly that policy, is changed theirs, it could enable others to adopt it, too. Well, I consider YAHOO to be a player that is major enough when the political questions arise. As for Microsoft and it's no open-source policy, well, until vista they have been using BSD network stack and had no problems with that as far as i can tell :) -Matej Jörn PS: I'm currently sitting on a panel with PPK and guys from Prototype, Dojo, YUI and jQuery. One question was: What library would you recommend but your own?. Two of the three non-jQuery guys recommened jQuery On Mon, Sep 29, 2008 at 1:41 PM, Matej Knopp [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 1:18 PM, Jörn Zaefferer [EMAIL PROTECTED] wrote: It would be a big plus for me if Wicket would adopt jQuery. Drupal does that, and anyone writing a Drupal module can rely on the fact that jQuery is available. Same for Wordpress, where plugin authors can rely on the availability of jQuery. And not having to load more than one library, internal or not, is a good thing performance-wise. In response to your examples: Unbinding only particular event handlers without having a reference to the handler function can be achieved with namespaces: $(element).bind(click.somethingUnique, handleClick); $(element).unbind(click.somethingUnique); But that's not quite the same. This requires me to use generate and keep a unique string. Anyway, this is a cosmetic issue only. That way you don't have to keep a reference at all, while its possible to group multiple events into one namespace. This is now heavily used by most jQuery UI components when destroyed, to clean up their own event handlers without affecting any other. Multiple file upload we'll eventually have as part of jQuery UI. That would then be the same level of official and supported component that YUI provides. The descision to add new components is partly community-driven. So if you think multipart ajax uploads should be added, just ask for it. This is not about multiple file upload. We already have such component in Wicket. This is about support for input type=file on ajax uploads - just use hidden frame instead of xml http request. About selectors: John Resig is currently working on a new selector engine that likely outperformances any other selector engine available so far. Its developed as a standalone library, so its likely that MochKit and Prototype will use it, too. That sure is nice, but the selectors are not used in Wicket core at all. jQuery 1.3. will also provide heavy performance improvements for DOM manipulations, which I'm very exited about as that is usually where most time is spent. Its easy to avoid running certain selectors too often, but its hard to optimize DOM manipulation in clientcode. While we at this, I'd like to ask. Significant part of Wicket ajax is Wicket.replaceOuterHtml method. This was really a major pain to implement and stabilize. What it does is basically a replaceOuterHTML call for all browser but it works in totally cross browser
Re: WANG–Wicket Ajax Next Generation–being based on YUI (MD)
and what happens when microsoft forks jquery and hires all of its developers to work on its proprietary version? to me this is more a risk then anything else -igor On Mon, Sep 29, 2008 at 2:13 PM, Jörn Zaefferer [EMAIL PROTECTED] wrote: I guess I didn't quite get the file upload example in the first place. Uploading via iframe is supported by jQuery's form plugin, which is one of the best plugins we have. We plan to add it, together with other related plugins, to jQuery UI forms (or something like that). About selectors: jQuery promotes progressive enhancement a lot, and selectors are essential for that. One example for that is that we avoid inline onclick=.. and similar stuff. I'm not sure how that would be handled by Wicket, and if using jQuery would open ways to handle things differently. I can't give you too many details on replaceOuterHtml, though that sounds like I can easily get more info on. Currently jQuery does a lot of work cleaning html input that is appended into the DOM, which seems to be basically the same usecase here. Also executing script-tags is something we cover. Could you give me an example how exactly replaceOuterHTML is currently used? About the Microsoft argument: True, from a technical perspective that doesn't matter. But its an important political aspect: I already read a few comments from people that couldn't use jQuery due to a general no open-source policy - but now that Microsoft, that had exactly that policy, is changed theirs, it could enable others to adopt it, too. Jörn PS: I'm currently sitting on a panel with PPK and guys from Prototype, Dojo, YUI and jQuery. One question was: What library would you recommend but your own?. Two of the three non-jQuery guys recommened jQuery On Mon, Sep 29, 2008 at 1:41 PM, Matej Knopp [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 1:18 PM, Jörn Zaefferer [EMAIL PROTECTED] wrote: It would be a big plus for me if Wicket would adopt jQuery. Drupal does that, and anyone writing a Drupal module can rely on the fact that jQuery is available. Same for Wordpress, where plugin authors can rely on the availability of jQuery. And not having to load more than one library, internal or not, is a good thing performance-wise. In response to your examples: Unbinding only particular event handlers without having a reference to the handler function can be achieved with namespaces: $(element).bind(click.somethingUnique, handleClick); $(element).unbind(click.somethingUnique); But that's not quite the same. This requires me to use generate and keep a unique string. Anyway, this is a cosmetic issue only. That way you don't have to keep a reference at all, while its possible to group multiple events into one namespace. This is now heavily used by most jQuery UI components when destroyed, to clean up their own event handlers without affecting any other. Multiple file upload we'll eventually have as part of jQuery UI. That would then be the same level of official and supported component that YUI provides. The descision to add new components is partly community-driven. So if you think multipart ajax uploads should be added, just ask for it. This is not about multiple file upload. We already have such component in Wicket. This is about support for input type=file on ajax uploads - just use hidden frame instead of xml http request. About selectors: John Resig is currently working on a new selector engine that likely outperformances any other selector engine available so far. Its developed as a standalone library, so its likely that MochKit and Prototype will use it, too. That sure is nice, but the selectors are not used in Wicket core at all. jQuery 1.3. will also provide heavy performance improvements for DOM manipulations, which I'm very exited about as that is usually where most time is spent. Its easy to avoid running certain selectors too often, but its hard to optimize DOM manipulation in clientcode. While we at this, I'd like to ask. Significant part of Wicket ajax is Wicket.replaceOuterHtml method. This was really a major pain to implement and stabilize. What it does is basically a replaceOuterHTML call for all browser but it works in totally cross browser consistent way. I.e. it allows table rows, cells etc replaced in internet explorer and it also executes embedded script tags on browsers that would normally not do that (basically all except for Firefox). So my question is, just out of curiosity, is there/will there be similar functionality provided by jQuery? Anyway, thanks for taking the time to discuss this again. Sure. Keep in mind that the decision is not carved to stone. I'm open to argument, but I'm really interested in technical aspect. Having Microsoft will use jQuery is not really a valid argument to me :) -Matej Jörn On Mon, Sep 29, 2008 at 12:54 PM, Matej Knopp [EMAIL PROTECTED] wrote: Are you really that surprised that Microsoft is
Re: WANG–Wicket Ajax Next Generation–being based on YUI (MD)
On Mon, Sep 29, 2008 at 11:13 PM, Jörn Zaefferer [EMAIL PROTECTED] wrote: PS: I'm currently sitting on a panel with PPK and guys from Prototype, Dojo, YUI and jQuery. One question was: What library would you recommend but your own?. Two of the three non-jQuery guys recommened jQuery So you're saying that 75% of the leading JS framework community think jquery is second best. Please keep the jquery marketing BS and fanboyism to the jquery forums. It serves nobody any good. In fact it makes me cringe and want to -1 any and all votes for adopting anything near jquery. Martijn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WANG–Wicket Ajax Next Generation–being based on YUI (MD)
Okay, let's keep this focused. Here is my experimental branch. http://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/ There is new Ajax implementation here: http://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/wicket/src/main/java/org/apache/_wicket/ajax/js/wicket-ajax-ng.js and the main AjaxBehavior here: http://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/wicket/src/main/java/org/apache/_wicket/ajax/AjaxBehavior.java What I'd like to hear is what exactly is wrong with it and how using jQuery (or any other framework for that matter) could improve things. -Matej On Mon, Sep 29, 2008 at 11:45 PM, Martijn Dashorst [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 11:13 PM, Jörn Zaefferer [EMAIL PROTECTED] wrote: PS: I'm currently sitting on a panel with PPK and guys from Prototype, Dojo, YUI and jQuery. One question was: What library would you recommend but your own?. Two of the three non-jQuery guys recommened jQuery So you're saying that 75% of the leading JS framework community think jquery is second best. Please keep the jquery marketing BS and fanboyism to the jquery forums. It serves nobody any good. In fact it makes me cringe and want to -1 any and all votes for adopting anything near jquery. Martijn - 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]
Re: WANG–Wicket Ajax Next Generation–being based on YUI (MD)
Wicket.replaceOuterHTML(element, newmarkup); would be this in jQuery: $(element).after(newmarkup).remove(); That inserts the new stuff after the element, then removes the element, leaving only the new content in the DOM. after() takes care of cleanup stuff for table colgroups, rows and cells, legends, options and so on. Jörn On Mon, Sep 29, 2008 at 11:31 PM, Matej Knopp [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 11:13 PM, Jörn Zaefferer [EMAIL PROTECTED] wrote: I guess I didn't quite get the file upload example in the first place. Uploading via iframe is supported by jQuery's form plugin, which is one of the best plugins we have. We plan to add it, together with other related plugins, to jQuery UI forms (or something like that). Well, that's what I'm talking about. It's a separate plugin. I don't know how good the plugin is. How actively it is mantained. Can I rely on it? Those are the questions I do not need to ask when dealing with YUI. About selectors: jQuery promotes progressive enhancement a lot, and selectors are essential for that. One example for that is that we avoid inline onclick=.. and similar stuff. I'm not sure how that would be handled by Wicket, and if using jQuery would open ways to handle things differently. In wicket 1.5 there won't be any inline handlers in the markup. All events will be attached separately. I can't give you too many details on replaceOuterHtml, though that sounds like I can easily get more info on. Currently jQuery does a lot of work cleaning html input that is appended into the DOM, which seems to be basically the same usecase here. Also executing script-tags is something we cover. Could you give me an example how exactly replaceOuterHTML is currently used? It is used every time Ajax request replaces component on page. Wicket.replaceOuterHTML(element, newmarkup); It replaces the element (the tag itself) with the new markup. But it takes care of some things such as when the element is a table row or cell, or if there are script tag embedded in the markup. About the Microsoft argument: True, from a technical perspective that doesn't matter. But its an important political aspect: I already read a few comments from people that couldn't use jQuery due to a general no open-source policy - but now that Microsoft, that had exactly that policy, is changed theirs, it could enable others to adopt it, too. Well, I consider YAHOO to be a player that is major enough when the political questions arise. As for Microsoft and it's no open-source policy, well, until vista they have been using BSD network stack and had no problems with that as far as i can tell :) -Matej Jörn PS: I'm currently sitting on a panel with PPK and guys from Prototype, Dojo, YUI and jQuery. One question was: What library would you recommend but your own?. Two of the three non-jQuery guys recommened jQuery On Mon, Sep 29, 2008 at 1:41 PM, Matej Knopp [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 1:18 PM, Jörn Zaefferer [EMAIL PROTECTED] wrote: It would be a big plus for me if Wicket would adopt jQuery. Drupal does that, and anyone writing a Drupal module can rely on the fact that jQuery is available. Same for Wordpress, where plugin authors can rely on the availability of jQuery. And not having to load more than one library, internal or not, is a good thing performance-wise. In response to your examples: Unbinding only particular event handlers without having a reference to the handler function can be achieved with namespaces: $(element).bind(click.somethingUnique, handleClick); $(element).unbind(click.somethingUnique); But that's not quite the same. This requires me to use generate and keep a unique string. Anyway, this is a cosmetic issue only. That way you don't have to keep a reference at all, while its possible to group multiple events into one namespace. This is now heavily used by most jQuery UI components when destroyed, to clean up their own event handlers without affecting any other. Multiple file upload we'll eventually have as part of jQuery UI. That would then be the same level of official and supported component that YUI provides. The descision to add new components is partly community-driven. So if you think multipart ajax uploads should be added, just ask for it. This is not about multiple file upload. We already have such component in Wicket. This is about support for input type=file on ajax uploads - just use hidden frame instead of xml http request. About selectors: John Resig is currently working on a new selector engine that likely outperformances any other selector engine available so far. Its developed as a standalone library, so its likely that MochKit and Prototype will use it, too. That sure is nice, but the selectors are not used in Wicket core at all. jQuery 1.3. will also provide heavy performance improvements for DOM manipulations, which I'm very exited about as that is
Re: WANG–Wicket Ajax Next Generation–being based on YUI (MD)
I'll go through a few things in the wicket-ajax-ng.js file, to give an
idea how that could look like when putting it on top of jQuery. I skip
all stuff where I can't guess while scanning the code whats its
supposed to do.
W.$ looks like it selects one or more elements by id. Selecting is
completely encapsulated in the jQuery-function, so you would change
the usage a bit:
W.$(myID) == $(#myID).get(0)
W.$(id1, id2) == $(#id1, #id2).get()
Usually you won't need to reference the DOM elements, so you could
remove the get(0) and get() calls.
W.$$ would just use:
if ($(#id).size() ) {
// element exists
}
copyArray can be replaced with jQuery.makeArray
(http://dev.jquery.com/browser/trunk/jquery/src/core.js#L1130), which
is heavily optimized and takes stuff like passing window as an
argument into account.
iterateArray could be replaced with jQuery.each, though the symantics
are slightly different. jQuery.each iterates over both objects and
arrays.
The GarbageCollector wouldn't be necessary: jQuery cleans up all event
listeneres when removing elements from the DOM. You don't have to
bother with that at all.
Like I mentioned earlier, replaceOuterHtmlXXX shouldn't be necessary
at all, jQuery handles that automatically for all DOM manipulation
methods.
mapToUrlParameters would be handled by jQuery.param. Though usually
when using jQuery's ajax methods, you don't have to worry about that.
For example, to post some parameters to the server, you'd just use
jQuery.ajax with the data option:
$.ajax({
url: ...,
method: post
data: {
key1: value1,
key2: value2
}
});
And so far I've covered only jQuery core functionality. What do you think?
Jörn
On Mon, Sep 29, 2008 at 11:50 PM, Matej Knopp [EMAIL PROTECTED] wrote:
Okay, let's keep this focused.
Here is my experimental branch.
http://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/
There is new Ajax implementation here:
http://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/wicket/src/main/java/org/apache/_wicket/ajax/js/wicket-ajax-ng.js
and the main AjaxBehavior here:
http://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/wicket/src/main/java/org/apache/_wicket/ajax/AjaxBehavior.java
What I'd like to hear is what exactly is wrong with it and how using
jQuery (or any other framework for that matter) could improve things.
-Matej
On Mon, Sep 29, 2008 at 11:45 PM, Martijn Dashorst
[EMAIL PROTECTED] wrote:
On Mon, Sep 29, 2008 at 11:13 PM, Jörn Zaefferer
[EMAIL PROTECTED] wrote:
PS: I'm currently sitting on a panel with PPK and guys from Prototype,
Dojo, YUI and jQuery. One question was: What library would you
recommend but your own?. Two of the three non-jQuery guys recommened
jQuery
So you're saying that 75% of the leading JS framework community think
jquery is second best.
Please keep the jquery marketing BS and fanboyism to the jquery
forums. It serves nobody any good. In fact it makes me cringe and want
to -1 any and all votes for adopting anything near jquery.
Martijn
-
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]
Re: WANG–Wicket Ajax Next Generation–being based on YUI (MD)
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 dragdrop, 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]
Re: WANG–Wicket Ajax Next Generation–being based on YUI (MD)
And Nokia http://www.s60.com/life/thisiss60/s60indetail/technologiesandfeatures/webruntime http://www.s60.com/life/thisiss60/s60indetail/technologiesandfeatures/webruntime/webruntimedetail 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 dragdrop, 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]
Re: WANG–Wicket Ajax Next Generation–being based on YUI (MD)
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 dragdrop, 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]
Re: WANG–Wicket Ajax Next Generation–being based on YUI (MD)
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. We too were tending towards jQuery, mainly because + code based on jQuery can be quite terse yet still easy to read and elegant. I think same goes for YUI, especially with YUI3 Node class. + it doesn't require any great Javascript expertise (in particular, no obvious cross-browser issues to worry about so far). I don't see how this is different than what YUI does + it's got a small footprint and seems to be fast enough, even using the (really useful) CSS selectors. CSS selectors are of no use for Wicket Ajax, of course they might be useful for the actual application or other components. However YUI also have CSS selectors, even though i haven't profiled them. Anyway, in general i don't think that CSS selector speed matters too much. For anything really have you would have to cache the results somehow (like i did for grid). + 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. + there's a big developer community/interest with plenty of reference material, blogs etc... + the lack of any licensing concerns. + it's really easy to use and it just works. Again, I don't see why this wouldn't apply to YUI as well. Since you have no doubt carefully looked at the options and chosen YUI as the most appropriate for Wicket 1.5 (or, shall we just call it Wicket 5), and having seen the magic you have performed with your inmethod grids, I imagine that most of the above can be said for YUI too, and then some. Could be :) So ... would it make more sense to start preferring YUI for use in new Wicket applications or will it not make any real difference which Javascript library is used by the application developer? Really it won't. I used YUI because i liked it more. I went through the jQuery source code when I was evaluating it and I found YUI to be much more readable. This is a personal opinion though. It's more about the approach. I like YUI approach to things. I like the way the YUI API is designed. It like the things that are in YUI core and that only are available as plugin to jquery. 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 :) -Matej Matej Knopp-2 wrote: Hi, I haven't announced yet publicly but for some time I was working on Ajax implementation for 1.5. The work is available in /repos/asf/wicket/sandbox/knopp/experimental/wicket I will put together a wiki page when I have some free time. I have of course considered jquery. I gave it a proper look but I decided to go with YUI instead because I like it's approach more. Also some functionality that YUI provides in core (dom manipulations) is only available as plugin to Jquery. New Wicket Ajax the is based on YUI3 which provides new node module that allows method chaining and kinda feels like jquery. Also personally I consider YUI source code much more readable than jquery -Matej On Tue, Aug 26, 2008 at 6:10 PM, Scott Swank [EMAIL PROTECTED] wrote: Has jquery been considered for WANG, or am I coming into this conversation late? Scott On Tue, Aug 26, 2008 at 5:51 AM, Martijn Dashorst [EMAIL PROTECTED] wrote: Probably something for 1.5 (with WANG–Wicket Ajax Next Generation–being based on YUI) Martijn On Tue, Aug 26, 2008 at 2:25 PM, Nino Saturnino Martinez Vazquez Wael [EMAIL PROTECTED] wrote: I've been hearing some rants on how merging resources can up the performance, should wicket be able todo this? I mean merging several css's into one etc.. I know it wont work for dynamic css/js/images. But on static it could, even yslow recommends you merge your resources into one... Images might be stretching it too far? WDYT? http://workingwithrails.com/railsplugin/5317-asset-packager http://www.kaboomerang.com/blog/2007/11/29/getting-to-10-actiontastic-actionatr-gwt-and-automagic-rest/ -- -Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To
Re: WANG–Wicket Ajax Next Generation–being based on YUI (MD)
I'm generally not against having push in core, so any suggestion about how the api should look like is appreciated. -Matej On Tue, Aug 26, 2008 at 11:12 PM, Peter Ertl [EMAIL PROTECTED] wrote: +1 for including support for cometd in wicket core I expect server side push the next great thing in web development :) my 2 pct Am 26.08.2008 um 22:19 schrieb Matej Knopp: 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. We too were tending towards jQuery, mainly because + code based on jQuery can be quite terse yet still easy to read and elegant. I think same goes for YUI, especially with YUI3 Node class. + it doesn't require any great Javascript expertise (in particular, no obvious cross-browser issues to worry about so far). I don't see how this is different than what YUI does + it's got a small footprint and seems to be fast enough, even using the (really useful) CSS selectors. CSS selectors are of no use for Wicket Ajax, of course they might be useful for the actual application or other components. However YUI also have CSS selectors, even though i haven't profiled them. Anyway, in general i don't think that CSS selector speed matters too much. For anything really have you would have to cache the results somehow (like i did for grid). + 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. + there's a big developer community/interest with plenty of reference material, blogs etc... + the lack of any licensing concerns. + it's really easy to use and it just works. Again, I don't see why this wouldn't apply to YUI as well. Since you have no doubt carefully looked at the options and chosen YUI as the most appropriate for Wicket 1.5 (or, shall we just call it Wicket 5), and having seen the magic you have performed with your inmethod grids, I imagine that most of the above can be said for YUI too, and then some. Could be :) So ... would it make more sense to start preferring YUI for use in new Wicket applications or will it not make any real difference which Javascript library is used by the application developer? Really it won't. I used YUI because i liked it more. I went through the jQuery source code when I was evaluating it and I found YUI to be much more readable. This is a personal opinion though. It's more about the approach. I like YUI approach to things. I like the way the YUI API is designed. It like the things that are in YUI core and that only are available as plugin to jquery. 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 :) -Matej Matej Knopp-2 wrote: Hi, I haven't announced yet publicly but for some time I was working on Ajax implementation for 1.5. The work is available in /repos/asf/wicket/sandbox/knopp/experimental/wicket I will put together a wiki page when I have some free time. I have of course considered jquery. I gave it a proper look but I decided to go with YUI instead because I like it's approach more. Also some functionality that YUI provides in core (dom manipulations) is only available as plugin to Jquery. New Wicket Ajax the is based on YUI3 which provides new node module that allows method chaining and kinda feels like jquery. Also personally I consider YUI source code much more readable than jquery -Matej On Tue, Aug 26, 2008 at 6:10 PM, Scott Swank [EMAIL PROTECTED] wrote: Has jquery been considered for WANG, or am I coming into this conversation late? Scott On Tue, Aug 26, 2008 at 5:51 AM, Martijn Dashorst [EMAIL PROTECTED] wrote: Probably something for 1.5 (with WANG–Wicket Ajax Next Generation–being based on YUI) Martijn On Tue, Aug 26, 2008 at 2:25 PM, Nino Saturnino Martinez Vazquez Wael [EMAIL PROTECTED] wrote: I've been hearing some rants on how merging resources can up the performance, should wicket be able todo this? I mean merging several css's into one etc.. I know it wont work for dynamic css/js/images. But on static it could, even yslow recommends you merge your
Re: WANG–Wicket Ajax Next Generation–being based on YUI (MD)
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 dragdrop, 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
