> From: Mike Alsup
>
> Mike Geary, I haven't yet implemented your outline.
> I like it stylistically, but I not expecting performance
> improvements. Would you agree or would you
> expect it to be faster than Renato's impl?
I think it depends on the nature of the form. For a form with a SELECT
c
> Where are you finding the Firebug timer? I'm not seeing much of a
> performance boost using the for loop, but without a true timer, it's not
> a fair test...
Look at the measurement section here:
http://www.joehewitt.com/software/firebug/docs.php
My test func looks like this:
$(function() {
ptember 28, 2006 6:22 AM
To: jQuery Discussion.
Subject: Re: [jQuery] Form plugin's serialize(): performance issues
> I agree with Brian about the need of a FastSerialize method.
Renato,
I've been benchmarking these serialize methods on a form with one select
element that has 2000 opti
> I agree with Brian about the need of a FastSerialize method.
Renato,
I've been benchmarking these serialize methods on a form with one
select element that has 2000 options. Using the Firebug timer to
capture elapsed time for the serialize call I see negligible
difference in your impl and the o
Brian ha scritto:
> Perhaps there should be a "FastSerialize" method, that doesn't guarantee
> semantic order, and uses every shortcut to cut down on dom-walking time?
> This way, the developer can choose whether to use the faster method, or
> the slower-but-correctly-ordered method.
>
> - Brian
Perhaps there should be a "FastSerialize" method, that doesn't guarantee
semantic order, and uses every shortcut to cut down on dom-walking time?
This way, the developer can choose whether to use the faster method, or
the slower-but-correctly-ordered method.
- Brian
>> Can you explain why proce
> Can you explain why processing elements in semantic order is important?
Hi Renato,
The reasoning behind keeping the elements in semantic order is to have
the form submit data to the server in EXACTLY the same order as it
would if javascript were disabled. For many, this is unimportant, but
som
> Can you explain why processing elements in semantic order is important?
Two reasons:
$("input | select").eq(0)
This should access the first matched element of input or select - when
the order isn't important, you'll never know which element will
actually be first. It's important that the eleme
> If you say jQuery doesn't support the OR selector '|', then I'm
> confused. I have a form with one SELECT element and several INPUTs.
> Check out the following results from Firebug:
>
> >>> $('INPUT', $('#myform')).length
> 6
> >>> $('INPUT|SELECT', $('#myform')).length
> 7
>
> That's what I exp
Mike Alsup ha scritto:
>> Believe it or not, make it a reverse for loop, it is even faster:
>
> Except that we want to process them in semantic order! :-)
>
Hi,
I read John and Mike pointed out the need to process form elements
keeping their order.
Can you explain why processing elements in se
UT|SELECT', $('#myform')).length
7
That's what I expected as a result.. can you explain?
m.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of John Resig
Sent: Wednesday, September 27, 2006 11:06 AM
To: jQuery Discussion.
Subject: Re: [j
> From: Mike Alsup
>
> Seems to be faster rewriting it with a for loop instead of using each.
> Matt, can you confirm?
Here's a skeleton of another way to approach the problem. Instead of
enumerating every element inside the form, it looks at each nodeName as it
goes and decides what to do from
> Believe it or not, make it a reverse for loop, it is even faster:
Except that we want to process them in semantic order! :-)
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Oops, I missed a 'return'. This:
if (el.type == 'image' && el.form.clicked_x)
return a.push(
{name: el.name+'_x', value: el.form.clicked_x},
{name: el.name+'_y', value: el.form.clicked_y}
);
Should be:
if (el.type == 'image' && el.form.clicked_x) {
a.pus
Mike Alsup schrieb:
> Seems to be faster rewriting it with a for loop instead of using each.
> Matt, can you confirm?
>
> Mike
Believe it or not, make it a reverse for loop, it is even faster:
for (var k = options.length - 1; k >= 0; k--) {
}
Cheers, Klaus
Seems to be faster rewriting it with a for loop instead of using each.
Matt, can you confirm?
Mike
$.fn.serialize = function() {
var a = [];
var ok = {INPUT:true, TEXTAREA:true, OPTION:true};
var els = this[0].getElementsByTagName("*");
var l = els.length;
Unfortunately, jQuery doesn't support the OR selector '|', otherwise
that'd work quite nicely. The problem is that I don't know how this
would work without using "*", and filtering away what you don't need -
while still keeping the order of all the elements that you want.
If anyone has any ideas,
I've run into a significant performance issue with the form plugin's
serialize method; not a bug per se, but definitely a show-stopper for
me. The problem is that I have a form with a select element, which has
around 250 options. The serialize method grabs *all* child elements of
the form before op
18 matches
Mail list logo
