Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations derfloh on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

simple php question 3

Status
Not open for further replies.

btween

Programmer
Aug 7, 2003
338
US
If I have a form with 5 checkboxes. They can all have the same label or different labels. For every checkbox that is checked, when the form is submitted the next page should display the total number of checkboxes checked.

in other words if the user checks 3 boxes i need the next page to display: your score is 3.

 
noone's disagreeing with you Vragabond!

I think all three of Cory, myself and Shadedecho has said something similar. the point of the post got a bit lost as the thread went on and it became an exercise in how a dynamically rendered form could maintain sticky checkboxes without explicit identifiers in the name.
 
vragabond-
I admit, I honestly didn't know this... it must've been something that has been changed or been made more consistent in the latest generations of browsers or server (php) software...i guess it's been too long since I visited this topic and I was going on what I learned/knew from years ago.

i tried vragabond's solution, and it is true that it maintains the indexing if you specify it manually. In fact, the same is true for non-numeric indexing... if you specify something like: name="cbox[abc def]" (notice no quotes around the index), what you get on the server side if you submit that box is $_POST["cbox"]["abc def"].

Be careful, it seems... If you put " or ' in the HTML definition around the desired index (name="cbox['abc def']"), those literal characters are included in the string index, so you get something like: $_POST["cbox"]["'abc def'"] which is probably not what is desired.

It appears as if from the server side, what is happening is that if you don't specify an index, it uses the PHP array shortcut syntax of [] to just append numerically to the end of the array. if you do supply an index, it tries first to make it a numerical index. so saying name="cbox[4]" makes if $_POST["cbox"][4]. I was not able in my testing to find a way to get it to be $_POST["cbox"]["4"]. So if the specified index CAN be a number, PHP seems to force it to be, assuming that is what you want. Interesting to note.

*******************************

Also, I took the time in some testing to try and look at the "value" attribute of checkboxes, and how it behaves in relation to PHP.

All I have to test with at the moment is IE6 on windows, so perhaps others can test as well on other browsers.

My results indicate in this environment if you don't specify a "value" attribute for the checkbox, PHP sets the value of the item in the $_POST array equal to the string "on". But, if you DO provide a string in the "value" attribute, this default is overridden. You can even say value="" in the checkbox definition and the empty string overrides the "on".

+++++++ SO ++++++++
It would appear we have come up with two different ways to solve this which involve jpadie's original "array" implementation. One would be (thanks to vragabond) to use specific indexes in the definition of the checkbox (like <input name="cbox[1]"...> or <input name="cbox[abc]"...>) and then as you are re-drawing the page, check to see if that index is set in the $_POST["cbox"] array, like:

Code:
if (array_key_exists("abc",$_POST["cbox"])) echo " CHECKED";

The other solution would be to use the value attribute to set certain values, like <input value="abc" name="cbox[]"...>, and again, to test as you are redrawing the boxes like:

Code:
if (in_array("abc",$_POST["cbox"])) echo " CHECKED";

Either way should give you good results, and is admittedly more clean than my original approach, which was to name the checkboxes individually.

-------------------------------------

Lastly, I wanted to point out, after retrospection, *why* my default behavior was the former, and not this cleaner method we have come across after much discussion...

for this type of scenario, as presented in the question, the solutions presented by jpadie, clflava, and vragabond indeed probably are the best ways.

however, i work a lot in AJAX environments where i have to have javascript interacting with the checkboxes in complicated ways. In that respect, Javascript *IS NOT* as friendly as PHP is in how it handles auto/magically special naming of your form elements to let you reference it.

If you have a bunch of checkboxes and you need to reference them individually in Javascript, they MUST have a unique id/name. You cannot rely on "cbox[]" to magically give you an array of them in Javascript, and you definitely cannot say "cbox[abc]" and then reference that one specifically using a string index. These methods appear to be artifacts of PHP only, which is nice, but your problem domain needs to dictate if you can utilize that nicety or not.

So, in my case, I end up doing a lot of stuff like: <input type="checkbox" name="abc_1_2_233_5" id="abc_1_2_233_5"> to hash together some meaningful/useful identifier for the checkbox, based on UI/business rules or hierarchies, that can be referenced both by javascript AND by php.
 
good post shadedecho.

for javascript: if i have to address one specific (or a small number) checkboxes or similar i set an id as you have indicated. for iterating across entire groups (for example a(n) (un)check-all button) could you not fudge the problem by getting a collection reference like this?
Code:
var cbox_collection = document.forms['myForm'].elements['cbox[]'];
var l = cbox_collection.length;
for (var i=0; i<l;i++){
 // do something
}
 
i'm not sure if "elements['cbox[]']" would work or not... something tells me that is not very cross-browser/cross-JS friendly. seems a bit in the gray area.

one thing to keep in mind though is that in truly heavily AJAX apps (usually browser targeted, but still...) it is very common to be adding and deleting form elements (rather than just hiding/unhiding them), and from my experience they don't always get added to the forms.elements collections as one would expect, or even in the same locations, etc. So, most of the time, we've had to resort to standard DOM referencing, using relative references like parent, child, and this. point is, you can quickly get to a level of complication in complex UI apps where you have no easy collections to iterate over, and no friendly auto-magical element naming characteristics to fall back on, and as such, the old fashioned way of manually naming/id'ing each element is all that is left.

anyway, since this is not a javascript forum, i think we should be careful not to veer too far off topic, so I'll leave it at this. definitely been good learning/refreshing for me.

btween--- have we answered your question (and then some)? :)
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top