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 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]
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
