PDA

View Full Version : grabbing all form data



ATMA
11-04-2007, 01:06 PM
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
11-04-2007, 03:25 PM
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
11-04-2007, 03:28 PM
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
11-04-2007, 05:21 PM
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
11-04-2007, 05:56 PM
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
11-04-2007, 06:26 PM
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
11-04-2007, 07:43 PM
Cool, I mean I haven't tested it, but it looks great now. Except, why declare n if it is only used once?

Twey
11-04-2007, 08:36 PM
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
11-05-2007, 05:00 AM
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
11-05-2007, 05:36 AM
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.

jscheuer1
11-05-2007, 05:51 AM
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.

I actually got that. I just would feel more confident of that actually being the case if n were defined before the initialization of the loop. Even then, given the propensity of javascript to 'do' (evaluate) each thing, each time it is referenced (it is after all a somewhat ******* language), I'm just not convinced of the savings in actual usage.

I applaud the concept.

ATMA
11-05-2007, 06:49 AM
ahh thank you every one lol that really helps and grabbing $_POST data wouldnt work with the methods im useing since in never even really sending $_POST data anyway :P AJAX(php style)

Twey
11-05-2007, 07:19 AM
I just would feel more confident of that actually being the case if n were defined before the initialization of the loop.Then, I'm not entirely sure I understand you. Why would defining n before the loop's initialisation section make you happier?

As for the concept, it's proven (http://batiste.dosimple.ch/blog/posts/2007-02-27-1/javascript-loop-benchmark.html). The exact scale of the improvement differs between browsers, but in all browsers I tested, the prefixed buffered loop was the fastest by a considerable margin.

jscheuer1
11-05-2007, 03:05 PM
That test proves nothing here, if I hit F5 in the browsers that the test page doesn't send into an endless loop, the results keep changing, with sometimes "Dumb standard loop" winning, sometimes others, but there is no consistency.

And I really was just about to stand up and cheer, honestly.

Twey
11-06-2007, 01:05 PM
That test proves nothing here, if I hit F5 in the browsers that the test page doesn't send into an endless loop, the results keep changing, with sometimes "Dumb standard loop" winning, sometimes others, but there is no consistency.Peculiar. Myself and a few others benchmarked this with various and got more-or-less the same I just got on that page using Konqueror. What browsers were you trying?

I should mention that it doesn't actually cause an endless loop, the for/in loop is just very slow on some browsers. It should get there eventually (but you should probably disable the 'this script is causing Browser X to run slowly...' prompts for accuracy).

jscheuer1
11-06-2007, 02:56 PM
I'm looking over Opera again. Most of the time it like 4 prefixed buffered decrement (15 to 16), but sometimes it is 31. Prefixed increment without buffer (2) comes in a close second or wins, then usually at 16 or 15, but sometimes is tied with the next two which are 1 dumb and 3 buffered inc (@31) with for in dead last (150 to 250 or so). There is no unbuffered decrement, Opera would probably love that.

FF, right now seems to pretty consistently like 4 (buffered dec) with the others all tied except for for in (poor for in, the biggest loser so far).

I'm going to let IE 7 run for awhile this time to see if it does anything. Oh, it got through it finally. It likes 4 as well with all the others tied again, except for in at slightly over 16000! I bet it would like 2 as often (like Opera does), but I don't want to put it through for in again to find out.

I'm thinking unbuffered prefixed decrement, untested on that page might have some real potential.

Trinithis
11-06-2007, 05:47 PM
Hmm, on FF, my computer tends to rank the results as such (fast to slow):
4 // --prefix
2 // ++prefix, no buffer
1 // ++postfix, no buffer
3 // ++prefix, buffer
5 // for-in

3 either tied with 1 or it (barely) seconded it. The funny thing is that I tested the buffered length before on my computer and it beat the old-fashion way. Perhaps we used different array sizes.

Regardless, I would be almost certain that the buffered length would win if there were more lookups to get to length, aka: a.b.length or so.

jscheuer1
11-06-2007, 06:08 PM
Yeah, it seems prefix is the real winner, buffer looks like it is slowing things down. I think the -- is best because, you start at the length, no longer need to check for it, and the 'target number' is 0, and can therefore never change during the loop. That type of loop would be unsuitable for some things though.