About removing events when removing elements: jQuery always removes
events when removing an element from the DOM. If you want to actually
move an element to insert it somewhere else, you can do that just as
well, you just may not use it with remove. Eg.
$(element).insertAfter(otherElement); will move element somewhere
else, keeping all events intact.
The replaceOuterHTML-replacement should be already heavily optimized,
though thats actually something that should work much better in jQuery
1.3, which is planned for fall 2008.
About get/post: True, if you use method: "post", all data-parameters
are posted. Though you can still just use $.param to seriliaze the
get-parameters and append it manually to the URL.
$.ajax({
url: "...?" + $.param(getParams),
data: postParams
});
Offset and position computations were part of the dimensions plugin,
which is now merged into jQuery core, so that is readily available and
official.
Jörn
On Tue, Sep 30, 2008 at 3:27 PM, Matej Knopp <[EMAIL PROTECTED]> wrote:
> Thanks for the response.
>
> On Tue, Sep 30, 2008 at 5:11 AM, Jörn Zaefferer
> <[EMAIL PROTECTED]> wrote:
>> I'll go through a few things in the wicket-ajax-ng.js file, to give an
>> idea how that could look like when putting it on top of jQuery. I skip
>> all stuff where I can't guess while scanning the code whats its
>> supposed to do.
>>
>> W.$ looks like it selects one or more elements by id. Selecting is
>> completely encapsulated in the jQuery-function, so you would change
>> the usage a bit:
>>
>> W.$("myID") == $("#myID").get(0)
>> W.$("id1", "id2") == $("#id1, #id2").get()
>>
>
> well, since we are not using any selector but # here, this is more
> like a cosmetic thing.
>
>> Usually you won't need to reference the DOM elements, so you could
>> remove the get(0) and get() calls.
>>
>> W.$$ would just use:
>>
>> if ($("#id").size() ) {
>> // element exists
>> }
> That's not entirely corrent i believe. If you pass element instance to
> W.$$ it checks if the element is part of active document. That's very
> important for wicket to determine if the queued ajax request is still
> valid.
>>
>> copyArray can be replaced with jQuery.makeArray
>> (http://dev.jquery.com/browser/trunk/jquery/src/core.js#L1130), which
>> is heavily optimized and takes stuff like passing window as an
>> argument into account.
> We only copy small arrays, the performance of array copy has never
> bothered me much :)
>>
>> iterateArray could be replaced with jQuery.each, though the symantics
>> are slightly different. jQuery.each iterates over both objects and
>> arrays.
>>
>> The GarbageCollector wouldn't be necessary: jQuery cleans up all event
>> listeneres when removing elements from the DOM. You don't have to
>> bother with that at all.
> Well, this is a rather unfortunate thing with YUI. If you bind event
> to element and then remove the element, yui only seem to release the
> element when window is being unloaded, which causes certain problems
> in IE. The memory consumption grows over time if you stay on single
> page, though it's not really a leak because the memory gets reclaimed
> on page reload. That's why i built the garbage collector that goes
> over elements and checks if they are still in the document.
>
> So I'm a bit curious here, how does jQuery know that element has been
> removed from document? And how does it know that I don't want to use
> it anymore? Or are all the events released when I use jQuery API to
> remove element from document? But what if i keep reference to that
> element myself (after removing it from the document) and I don't want
> the events to be removed (this part isn't really solved with current
> version of the "Garbage Collectior" either).
>
>>
>> Like I mentioned earlier, replaceOuterHtmlXXX shouldn't be necessary
>> at all, jQuery handles that automatically for all DOM manipulation
>> methods.
> That's a good news if the method really works as advertised (plus has
> decent performance for replacing large chunks of markup, which I'd
> have to test first though).
>
>>
>> mapToUrlParameters would be handled by jQuery.param. Though usually
>> when using jQuery's ajax methods, you don't have to worry about that.
>> For example, to post some parameters to the server, you'd just use
>> jQuery.ajax with the data option:
>
> Sure, as long as jQuery allows me to make distinction between GET and
> POST parameters. If it doesn't, I'd still have to encode the
> parameters for query string myself.
>
>>
>> $.ajax({
>> url: ...,
>> method: "post"
>> data: {
>> key1: "value1",
>> key2: "value2"
>> }
>> });
>>
>> And so far I've covered only jQuery core functionality. What do you think?
>
> Well, so far the element replacement method would be a benefit if it
> really works like Wicket.replaceOuterHTML does. As well as no
> "leaking" when removing elements with attached events from document,
> if it, indeed, works :)
>
> One thing that has crossed my mind too. YUI contains API for getting
> "absolute" coordinates of element as well as settings absolute
> coordinates to element (it takes care of setting proper position
> attributes, etc.). Last time I checked this was only 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]
>
>
