OK, I've made several modifications thanks to your suggestions and
corrections. This is publishable; should I go ahead and create a new
wiki page under Plugins or maybe wait until it's decided whether this
will be merged somehow with the existing form plugin?
m.
---
$.fn.fastSerialize = function
Good point, Jörn. Not only would you want to be able to submit an empty
string value for an option, but if the "value" attribute is excluded
from the option tag, this.value will return the text between the tags
anyway.
m.
On Tue, 2006-10-03 at 11:17 +0200, Jörn Zaefferer wrote:
> Matt Grimm schri
The "option:selected" is the only syntax that has worked for me in the
past. The XPath method only gets those options that literally have an
attribute of "selected" in the XHTML.
I also agree with you on the matter of excluding this.id as a fallback
for n. It's unnecessary and possibly confusing b
Good call, I've updated it to use your syntax for "f". Added benefit:
the selector reads "f this".
m.
On Tue, 2006-10-03 at 00:35 -0700, Michael Geary wrote:
> Nice.
>
> You could simplify this:
>
> var f = ['INPUT', 'TEXTAREA', 'SELECT', 'BUTTON'];
> $(f.join(','), this).each(function(
Thanks for catching this Klaus, I've updated the code to normalize tag
names.
m.
On Tue, 2006-10-03 at 11:21 +0200, Klaus Hartl wrote:
>
> Klaus Hartl schrieb:
> > Please make it XHTML as XML compatible (hm, why is it always me
> > complaining about that?)...:
>
>
> There's missing a part, I'
I don't think that's proper behavior, though. *Both* values of foo should
be posted if both are present. So, you'd either get "foo=offValue", or
"foo=offValue,onValue".
Either way, your backend code shouldn't break if the submitted fields are
in the wrong order.
- Brian
> On 10/3/06, Mike Als
Webunity | Gilles van den Hoven schrieb:
> Mike Alsup wrote:
>
>> Or better yet:
>>
>> $('option:selected')...
>>
>>
> Hey Mike, is that supported by jQuery? If i am right, only a plugin adds
> that method of selecting..
>
I dunno since when, but it is in the core. Maybe post-1.0.
-
This would still work. Semantic ordering will be retained within
element type, just not cross-type. In Matt's method you'd get all the
inputs (in order), then all the textareas, etc.
Mike
> Yes, I care.
>
> Case:
> An unchecked checkbox doesn't post. However, you usually want to work
> with an
That would actually have to ripple through all three methods in the
form plugin, not just the serialize method.
On 10/3/06, Brian <[EMAIL PROTECTED]> wrote:
> I'd say that .serialize() should take a boolean argument, "retainOrder",
> which will retain semantic order if true, and not if false/null
Mike Alsup wrote:
> Or better yet:
>
> $('option:selected')...
>
Hey Mike, is that supported by jQuery? If i am right, only a plugin adds
that method of selecting..
-- Gilles
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
On 10/3/06, Mike Alsup <[EMAIL PROTECTED]> wrote:
> So I think this new serialize method is pretty damn good! Is there
> *anyone* out there that cares about the semantic ordering of the
> posted values? Personally, I do not, and I definitely would like to
> have only a single serialize method. M
Or better yet:
$('option:selected')...
Also, I think I'd get rid of this:
var n = this.name || this.id;
because the id should not be used for the name. I think that's always
been wrong and it would result in a different behavior when javascript
is disabled.
Mike
On 10/3/06, Webunity | Gilles
I'd say that .serialize() should take a boolean argument, "retainOrder",
which will retain semantic order if true, and not if false/null/not
entered. That would be perfect.
The documentation should then make clear that the "retainOrder" option
will be slower for large forms.
- Brian
> I wonder
Mat,
This code:
> if (t == 'select-multiple') {
> $('option', this).each( function() {
> if (this.selected)
> a.push({name: n, value: this.value ||
> $(this).text()});
> });
> return;
> }
Can be changed to this, if i am right ;)
>
Very nice, Matt. This serialize method is way faster if the select
element is not a "multiple" select which I assume is how you
benchmarked it. When the select is a multiple-select then I see
basically the same performance with the for-loop impl posted on the
other thread. I did a quick test and
Hi,
I've introduced the optimizations proposed by Matt in the serialize
version I've already posted (var t = this.type).
http://zone.spip.org/trac/spip-zone/browser/_plugins_/_dev_/-jQuery/form.js
Renato
___
jQuery mailing list
discuss@jquery.com
htt
Klaus Hartl schrieb:
> Please make it XHTML as XML compatible (hm, why is it always me
> complaining about that?)...:
There's missing a part, I'm sorry, please normalize tag names:
var f = ['input', 'textarea', 'select', 'button'];
and
this.tagName.toLowerCase() == 'select'
Thank you,
Matt Grimm schrieb:
> Hello,
>
> I've put together a fast form serializer function that I'm hoping can
> get some review from the list for completeness, bugs, a better name,
> etc. A previous thread revealed quite a performance issue with the form
> plugin's existing serialize function when oper
Matt Grimm schrieb:
> I've put together a fast form serializer function that I'm hoping can
> get some review from the list for completeness, bugs, a better name,
> etc. A previous thread revealed quite a performance issue with the form
> plugin's existing serialize function when operating on a for
Nice.
You could simplify this:
var f = ['INPUT', 'TEXTAREA', 'SELECT', 'BUTTON'];
$(f.join(','), this).each(function() {
to:
var f = 'INPUT,TEXTAREA,SELECT,BUTTON';
$(f, this).each(function() {
BTW, what do you mean when you say it isn't a plugin? Looks like one to me.
:-)
-Mi
Hello,
I've put together a fast form serializer function that I'm hoping can
get some review from the list for completeness, bugs, a better name,
etc. A previous thread revealed quite a performance issue with the form
plugin's existing serialize function when operating on a form with a
large numbe
21 matches
Mail list logo
