form serialization (Code Worth Recommending Project)

[Peter Michaux]

[snip]

// In a seperate file define the wrapper function
// which automatically wraps the serializeFormUrlencoded
// function.

if (typeof serializeFormUrlencoded != 'undefined') {

serializeFormUrlencoded = (function() {

var original = serializeFormUrlencoded;

return function(f, options) {
var extras = [];
if (options && options.extras) {
var oes = options.extras;
for (var i=0, ilen=oes.length; i<ilen; i++) {
extras[extras.length] = urlencode(oes.key) +
'=' +
urlencode(oes.value);
}
}
var result = original.apply(this, arguments);
Why not just call original(f)?

If multiple wrappers are used (as they are in the Ajax code I'm
working on) then inner wrappers may depend on other properties of the
options object.

Okay, change that to original(f, options).

I don't know why I fell into the pattern of using apply or call for
this. I used it all through the wrappers of my Ajax code I've been
playing with recently. There must have been a really great reason at
some point

I believe you are right and that original(f, options) is better.

Peter

 

[Peter Michaux]

Peter Michaux wrote:

That doesn't seem unreasonable as a general principle, but one aspect of
the multiple implementations strategy is that there are contexts where
enough can be known up-front to eliminate the need for feature testing
(mostly Intranets, particularly the IE only ones).

Yes I meant those rules for scripts destined for the general web. I
will add this to the principles and post them in the project wiki.

[snip]

Ice Browser has a bug where the - type - of a select element is always
reported as "select" regardless of whether it is 'multiple' or 'one',
but the boolean - multiple - property of the element is appropriately
set.

Oh joy! Here is a new version...

if (typeof urlencode != 'undefined' &&
typeof getOptionValue != 'undefined' &&
String.prototype.match) {

var serializeFormUrlencoded = function(f) {
var e, // form element
n, // form element's name
t, // form element's type
o, // option element
es = f.elements,
c = []; // the serialization data parts

function add(n, v) {
c[c.length] = urlencode(n) + "=" + urlencode(v);
}

for (var i=0, ilen=es.length; i<ilen; i++) {
e = es;
n = e.name;
if (n && !e.disabled) {
t = e.type;
if (t.match(/^select/)) {
// The 'select-one' case could reuse 'select-multiple' case
// The 'select-one' case code is an optimization for
// serialization processing time.
if (t == 'select-one' || !e.multiple) {

Perhaps a little more cautious would be the following in case an
implementation does not have the multiple property.

if (t == 'select-one' || e.multiple === false) {

Peter

 

[David Mark]

[snip]

Perhaps a little more cautious would be the following in case an
implementation does not have the multiple property.

if (t == 'select-one' || e.multiple === false) {

I ended up with:

if (t == 'select-one' || (t == 'select' && !t.multiple)) {

That way a standard implementation will never check the multiple flag.

 

[Peter Michaux]

[snip]

Perhaps a little more cautious would be the following in case an
implementation does not have the multiple property.

if (t == 'select-one' || e.multiple === false) {

I ended up with:

if (t == 'select-one' || (t == 'select' && !t.multiple)) {

That way a standard implementation will never check the multiple flag.

I think the same is true in mine due to how || short circuits.

In yours if t == 'select' and t.multiple is undefined then the select-
one branch runs when really the select-multiple branch should run as
it is more general.

Peter

 

[David Mark]

[snip]

Perhaps a little more cautious would be the following in case an
implementation does not have the multiple property.
if (t == 'select-one' || e.multiple === false) {

I ended up with:

if (t == 'select-one' || (t == 'select' && !t.multiple)) {

That way a standard implementation will never check the multiple flag.

I think the same is true in mine due to how || short circuits.

If it is a multiple select, in standard implementations, it will check
the multiple property as the first condition (t == 'select-one') will
be false. The second one will be false as well, so it will then
proceed to the select-multiple branch.

In yours if t == 'select' and t.multiple is undefined then the select-
one branch runs when really the select-multiple branch should run as
it is more general.

That's true. I should change it to use the strict comparison.

 

[Peter Michaux]

[snip]
Perhaps a little more cautious would be the following in case an
implementation does not have the multiple property.
if (t == 'select-one' || e.multiple === false) {
I ended up with:
if (t == 'select-one' || (t == 'select' && !t.multiple)) {
That way a standard implementation will never check the multiple flag.

I think the same is true in mine due to how || short circuits.

If it is a multiple select, in standard implementations, it will check
the multiple property as the first condition (t == 'select-one') will
be false. The second one will be false as well, so it will then
proceed to the select-multiple branch.

You are right. I'm getting blurry eyed.