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
>
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)
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)
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]
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
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)
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)
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)
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)
Wicket.replaceOuterHTML(element, ""); would be this in jQuery:
$(element).after("").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, "");
> 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 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 Prototyp
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)
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)
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 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
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, "");
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 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 re
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 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
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 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
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 mi
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
>>> 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 le
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 >>> 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 uns
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 >>> 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]
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 >> 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] > >
Re: "WANG–Wicket Ajax Next Generation–being based on YUI" (MD)
>> >> 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 >> You can have annotation based validation already. It is possible to do even with Wicket 1.3. I don't see how that is related to comet support. -Matej - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: "WANG–Wicket Ajax Next Generation–being based on YUI" (MD)
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]
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 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
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) >> >> M
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-
