grabbing all form data

[ATMA]

i was wondering if anyone knew a way where i could grab all the form data of a bunch of fields inside the form all at once? is there a way to easily and quickly do this?

[jscheuer1]

Those values are already available as a part of the form's elements collection. There is no real need to 'gather' them. But, if you must:

var a=[];
for (var i = 0, e=form.elements; i < e.length; i++)
a[i]=e[i].value;

where form represents a reference to the form in question. This will give you an array of the values named a. If we knew the specifics of the project, especially what you wanted to do with the data, we could probably be more helpful.

Technically though, a form element, even if it has a value, has no data if it has no name. The above would gather information even from form elements with no name. But, it all depends upon what you want to do.

[djr33]

Note that if you are collecting this data serverside, you could just use $_POST (or $_GET). Might be better, in the end, depending on your goals.

[Twey]

function formToObject(frm) {
  for(var i = 0, r = {}, f = frm.elements, n = f.length; i < n; ++i)
    if(f[i].name)
      if(!r.hasOwnProperty([f[i].name]))
        r[f[i].name] = f[i].value;
      else if(r[f[i].name] instanceof Array)
        r[f[i].name].push(f[i].value);
      else
        r[f[i].name] = [r[f[i].name], f[i].value];
  return r;
}

[jscheuer1]

There is also (when using javascript to do this) the matter of - say radio buttons that each may have different values, but the same name, and one or none of them may be checked. The data (value) for that name would technically be empty if none were checked and be only that of the checked button if one is checked.

With Twey's code (which he may edit if I am right about this), I don't see how incrementing i would do anything to change n, resulting in only one element being processed over and over. I may have missed something.

[Twey]

You're quite right. I was writing it on autopilot, and I think I may have become sidetracked with some thought of mathematical functions 'f(n)' or such.

The radio/check boxes are easily solved:

function formToObject(frm) {
  for(var i = 0, r = {}, f = frm.elements, n = f.length; i < n; ++i)
    if(f[i].name && f[i].checked !== false)
      if(!r.hasOwnProperty([f[i].name]))
        r[f[i].name] = f[i].value;
      else if(r[f[i].name] instanceof Array)
        r[f[i].name].push(f[i].value);
      else
        r[f[i].name] = [r[f[i].name], f[i].value];
  return r;
}

[jscheuer1]

Cool, I mean I haven't tested it, but it looks great now. Except, why declare n if it is only used once?

[Twey]

It's a tiny optimisation tweak. Accessing a .length property is actually relatively computationally expensive, it's quite a bit cheaper to access it once and then store it if you know the length isn't going to change during the loop.

[jscheuer1]

It's a tiny optimisation tweak.

I understand the concept. If:

i < n

were to be evaluated during every loop, it would be (if applied to all such looping arguments that have no chance of n modulating during any given set loop instance) a minor to significant resource savings, depending upon the number of times such a construct could be substituted for the more normal/conventional (in this case):

for(var i = 0, r = {}, f = frm.elements; i < f.length; ++i)

I'm just not sure that any, or many javascript parsing engines would 'give a rat's a**', that is , treat the loop any differently, as far as resource requirements are concerned, and, if so, some or all might require slightly more resources.

Usually, the more code you write, however well intentioned, simply requires more parsing and/or processing.

Even when it doesn't, it is often a ratio to the number of times you use the extra code. The more times 'n' is used, the more of a savings it represents (if it still represents its original object/value. Is 'n' in this case really being reused more efficiently than f.length would be? I'm not convinced, but it could be. I would feel more confident if 'n' were defined before the loop began.

Even then, the declared definition might need to be evaluated with each loop.

In another matter, as nice as the code looks (it looks great!), and my above speculations with or without standing, I still haven't gotten around to testing it, and who knows if it (or any of the other suggestions in this thread) solves the original problem posted by ATMA. Oh, ATMA could tell us perhaps

[Twey]

Even when it doesn't, it is often a ratio to the number of times you use the extra code. The more times 'n' is used, the more of a savings it represents (if it still represents its original object/value. Is 'n' in this case really being reused more efficiently than f.length would be? I'm not convinced, but it could be. I would feel more confident if 'n' were defined before the loop began.

You're missing the point. It's not about how it's reused: the .length property calculates the length of the array on access. Since we know the array's length isn't going to change here, we can avoid that overhead by only calculating it once and storing it in n.