Array is really confusing.. OMG

[Monkuar]

I have a field name, secH..

 

when a user submit it's My MYSQL Update query is:

 

'lastupdate' => $updatetime,
'secH'    => $ibforums->input['secH'],
)      );
$DB->query("UPDATE ibf_members SET $db_string WHERE id='{$this->member['id']}'");
         $this->lib->do_signature_2();

 

I need, it to update so it's like this order:

 

1,2,1,1,0,1[/quote]

so then that user with field name sech will be updated with the order of [code]1,2,1,1,0,1

 

but then if a user unchecks the check box and saves how do i display it back  to the order of 0 ?

[ignace]

<input type="hidden" name="checkboxName" value="0">
<input type="checkbox" name="checkboxName" value="1">

 

Now if the checkbox is checked it returns the value 1 otherwise it will return 0 because of the hidden field with the same name and a value

 

[JonnoTheDev]

Now if the checkbox is checked it returns the value 1 otherwise it will return 0 because of the hidden field with the same name and a value

Why would you do that? You only need 1 field with that name. Check its value when sent to the server:

// can only be a 1 or 0
$checkVal = ($_POST['checkboxName']) ? 1 : 0;

 

Get rid of that hidden field with the same name

[ignace]

Why would you do that? You only need 1 field with that name. Check its value when sent to the server:

 

Because:

 

1) You don't need additional php code ($_POST['checkboxName'] will do the trick)

2) You also can use strings as a checked and unchecked value (although this also works with the ternary operation it is view data per se)

3) Maintaining is easy because you only need to worry about $_POST['checkboxName'] and the data only needs to be modified in the html document (1 html document - * php documents) I reckon that you can use a function for this but doing for every ternary operation is redundant

[JonnoTheDev]

You don't need additional php code ($_POST['checkboxName'] will do the trick)

So for every time I use a checkbox I need a hidden field. What if you had 100 checkboxes? Absolute garbage. I have never see a form work this way in my life.

 

As far as additional php code it is minimal

[Philip]

Yeah, that's kinda bad practice to have an extra hidden field.

 

And this should be the following to avoid any notices/warnings:

$checkVal = (isset($_POST['checkboxName'])) ? 1 : 0;

[.josh]

 

If I understand correctly you have for instance

 

<input type = 'checkbox' name='someArray[]' value='1' />

<input type = 'checkbox' name='someArray[]' value='1' />

<input type = 'checkbox' name='someArray[]' value='1' />

etc...

 

and do not want to lose the value of 0 or the array position for it if the user does not check one, right?

 

The easier thing to do would be to specify the array position in the form. 

 

<input type = 'checkbox' name='someArray[0]' value='1' />

<input type = 'checkbox' name='someArray[1]' value='1' />

<input type = 'checkbox' name='someArray[2]' value='1' />

etc...

 

Assuming you are displaying the checkboxes from a loop, you can just use a simple $x++ to inc it.  Or if purpose is to simply keep track of id's being checked, and assuming all ids are unique, you can just use the id as the array key and then the value won't even matter.

[ignace]

What if you had 100 checkboxes?

 

This goes also for your technique pal 100 ternary operations? And now think that this html document interfaces with multiple php documents (ajax) or is used as a partial for many documents, must be fun to edit each and every php file (ternary operation)

 

If you otherwise would just have to alter that stupid hidden and checkbox value which would be done in 2 seconds. And if it is such a bad practice then why is this also used within the Zend framework?

[trq]

And if it is such a bad practice then why is this also used within the Zend framework?

 

Pfff, where?

[JonnoTheDev]

And if it is such a bad practice then why is this also used within the Zend framework?

Bollo****

 

This goes also for your technique pal 100 ternary operations?

You wouldn't. A loop would be used!

 

Face it you have no one agreeing with your method. It is spaghetti code. End of

[.josh]

It is spaghetti code.

 

Umm..no...that's not what spaghetti code means.  Spaghetti code is where you fashion your code in such a way where the program flow jumps all over the place, most highly popularized by the use of a "goto" type function. 

[ignace]

This goes also for your technique pal 100 ternary operations?

You wouldn't. A loop would be used!

 

Right! All 1 or 0? Never ever a string of some sort.. Oh no wait we'll just add an if to our loop and a while later hey let's add an if to our loop and a while later hey let's add an if to our loop... Good thing you know what spaghetti code is

 

It is spaghetti code

 

Technically it's a hack.

 

Pfff, where?

 

Know your framework..

[Philip]

This goes also for your technique pal 100 ternary operations?

You wouldn't. A loop would be used!

 

Right! All 1 or 0? Never ever a string of some sort.. Oh no wait we'll just add an if to our loop and a while later hey let's add an if to our loop and a while later hey let's add an if to our loop... Good thing you know what spaghetti code is

 

It is spaghetti code

 

Technically it's a hack.

 

Pfff, where?

 

Know your framework..

 

It just doesn't make sense, because you already should be checking it server side to make sure the value is still correct. With your method - the fallback hidden field, I could easily forget that I need to check to make sure it is a 1 or 0 and nothing else. If I'm already checking for for the correct data type, I might as well just see if there is a checkbox field, and if so put my own default on there.

[ignace]

It just doesn't make sense, because you already should be checking it server side to make sure the value is still correct. With your method - the fallback hidden field, I could easily forget that I need to check to make sure it is a 1 or 0 and nothing else. If I'm already checking for for the correct data type, I might as well just see if there is a checkbox field, and if so put my own default on there.

 

You would do this:

$postdata = $_POST['data'] ? 1 : 0;
$postdata = validate_postdata($postdata);

 

And I would do this:

$postdata = validate_postdata($postdata);

 

Which in the very essence is the same except that your method if i may say is redundant:

//HTML:
<input type="checkbox" name="gender" value="male">
//PHP:
$gender = $_POST['gender'] === 'male' ? 'male' : 'female';

 

While my method adds the ternary operation client-side plus this doesn't imply a security risk as both methods use validators. But this is a fight that no one can win as you will still be using your ternary operation and i will be using my hidden field technique

[.josh]

All I'm saying is that relying on clientside code for anything is a security risk.  Therefore to overcome that, you will have to do serverside validation anyways.  So there is absolutely nothing you can do clientside that won't involve you doing double work in the end.  That's why I feel that it is pointless to do this.  With other clientside things like AJAX, at least the *bling* involved in doing it makes it worth the extra effort.  But this thing here; something working behind the scenes, provides no better experience or functionality for the user. There's nothing to make up for this double work. 

[ignace]

All I'm saying is that relying on clientside code for anything is a security risk. 

 

Ok fair enough. Then tell me the security risks of this one:

<input type="hidden" name="checkboxName" value="something">
<input type="checkbox" name="checkboxName" value="something_else">

$checkboxName = perform_validation($_POST['checkboxName']);

 

And how this one is not affected:

<input type="checkbox" name="checkboxName" value="something_else">

$checkboxName = $_POST['checkboxName'] ? 'something_else' : 'something';
$checkboxName = perform_validation($checkboxName);

 

In my opinion:

$checkboxName = $_POST['checkboxName'] ? 'something_else' : 'something';

I can pass anything that php evaluates to true or anything php evaluates to false while not getting any form errors. While my method will make sure that the entered data is valid.

 

You are a really respected member of this community and I am really interested in hearing your arguments.

[.josh]

You are a really respected member of this community and I am really interested in hearing your arguments.

 

Dunno about all that...anyways...

 

my method will make sure that the entered data is valid.

Method A:

<input type="hidden" name="checkboxName" value="something">
<input type="checkbox" name="checkboxName" value="something_else">

$checkboxName = perform_validation($_POST['checkboxName']);

 

Assuming that perform_validation() performs validation, yes, you are indeed validating the data.  But you are setting the default value client-side.  Since anybody can change the default value client-side, you are effectively allowing the user to pass anything to perform_validation().  Therefore, perform_validation will have to be scripted to handle that.  So at best, if perform_validation() is scripted right, setting a default value clientside is superfluous.  At worst, it is a potential security risk, because the user might be able to change the default value to something you didn't think about checking for in perform_validation().

 

I can pass anything that php evaluates to true or anything php evaluates to false while not getting any form errors.

Method B:

<input type="checkbox" name="checkboxName" value="something_else">

$checkboxName = $_POST['checkboxName'] ? 'something_else' : 'something';
$checkboxName = perform_validation($checkboxName);

 

No matter what the user sends, it is either going to be changed to 'something_else' or 'something'.  Theoretically, with this method, you don't even need to call perform_validation(), as the strings assigned by the ternary is the validation.

 

[JonnoTheDev]

No matter what the user sends, it is either going to be changed to 'something_else' or 'something'.  Theoretically, with this method, you don't even need to call perform_validation(), as the strings assigned by the ternary is the validation.

 

Thank you

[haku]

Good clear answer CV.

[ignace]

But you are setting the default value client-side.

 

I am not setting anything client-side. For example:

 

<input type="hidden" name="subscription" value="unsubscribe">
<input type="checkbox" name="subscription" value="subscribe">

 

Then i perform validation and this only allows 2 values: subscribe or unsubscribe (anything else is considered incorrect and if it is a required field it will keep displaying you this form over and over again until it gets unsubscribe or subscribe and if it is not a required field then it would default to its internal state wether checked or unchecked (server-side)). While you would allow: "", "0", 0, NULL, FALSE (these would all pass as unsubscribe and all others as subscribe). Please enlighten me why this is better? I don't want to be an asshole here or anything I just like a good discussion and I just want to know all angles (we are here to learn and I am no different). And what amazes me even more is why if this is so wrong it is used in the Zend framework?

 

<?php

class TestForm extends Zend_Form
{
    public function init() {
        $e = $this->createElement('Checkbox', 'subscription');
        $e->setCheckedValue('subscribe');
        $e->setUncheckedValue('unsubscribe');
        $this->addElement($e);
    }
}

 

Generates the hidden field + the checkbox field.

 

P.S. Sorry monkuar for screwing up your thread here

[.josh]

But you are setting the default value client-side.

 

I am not setting anything client-side. For example:

 

<input type="hidden" name="subscription" value="unsubscribe">
<input type="checkbox" name="subscription" value="subscribe">

 

Yes you are setting something client-side.  You are setting a default value. 

 

Then i perform validation and this only allows 2 values: subscribe or unsubscribe (anything else is considered incorrect and if it is a required field it will keep displaying you this form over and over again until it gets unsubscribe or subscribe).

 

Right. Since you are turning around and validating it server-side, and checking that it's either one or the other, that makes setting the default value in the form superfluous.  And to boot: how would you check for allowing only 2 values?  You know, I think a ternary would work just fine.  Coincidentally, method B already used one.  The difference is that in your 2 examples you put that ternary outside of your validating function in method B, whereas right here you are saying that the ternary (or similar condition) would be inside your validating function. 

 

In method B, that ternary would be inside the function in the first place, or else there would be no validation function (because a simple on/off would not require it), so in essence, both methods boil down to doing the same exact thing on the server-side, but method A has more client-side coding.  Why? Because in this case, you can achieve the same thing by virtue of whether the variable exists or not (or is null, "", "0", etc...)

 

While you would allow: "", "0", 0, NULL, FALSE (these would all pass as unsubscribe and all others as subscribe).

 

But for intents and purposes, these are all effectively the same thing, so what does that really matter? 

 

The point is, in this instance, a checkbox is acting like an on/off switch.  Either it is on or it is not.  Who cares whether the user tries to change the value or not.  Bottom line is that it's either on or it's off.  Therefore, you can use a simple ternary to assign one thing if it is on (variable exists), another if it is off (variable does not exist). 

 

Are you really proposing that the server-side scripting should somehow further decide whether it is on or off, based on what a user may or may not do to alter the checkbox value?  Sure, you can do things like log it as someone potentially trying to hack your system, but you would still be doing that under any scenario, so that's not really something to differentiate these two scenarios. 

 

I'm sorry, but I'm just not really coming up with a good reason why you would (or should) bother with kicking back an error to the user if they try to alter a hidden field. "I'm sorry, you have incorrectly filled out this form.  Please try again."  In the grand scheme of things, there is no reason not to assume a value sent == on, value not sent == off (other than logging it or doing whatever, based on previous paragraph). 

 

I don't even know if that bit of code really does what you claim it does.  Assuming it does do what you say it does... It sets up a default hidden value of 'subscribe', and a user can over-ride that by checking a visible 'unsubscribe' checkbox.  (I assume, based on the context of the code, and the context of this thread). 

 

But I'm trying to sit here and think of why that's really necessary, and I'm drawing a blank. Why can't they just assume in the server-side form processing script 'subscribe' and override it based on the existence of the 'unsubscribe' variable?  Seriously, I can't think of a reason why not, can you?  Which makes adding that hidden field superfluous. 

 

In general, just because the Zend framework does something, doesn't automatically make it the right thing to do.  Last time I checked, it was made by mere mortals, same as the rest of us mere mortals.

 

But nonetheless, I can't really respond to why it is done in the Zend framework.  I'm not really familiar with it.  It is an entire framework, not an isolate instance like this here.  There could be a lot of reasons why overall it might be better, within the scope of a framework.  In general, a framework is meant to cover not just a single instance of something, but cover all sorts of scenarios. 

 

[ignace]

You know, I think a ternary would work just fine

 

I never said it was bad nor did i say it wouldn't work but I'm going to leave it with this. Like I already said you are a respected member of this community and i respect your opinion on things and you are right maybe i'm making a to big fuss about it and I now know the pros and cons of using both techniques (I am just someone who doesn't easily do A just because someone said A is better). Anyway thanks for clearing this out!

[.josh]

You know, I think a ternary would work just fine

 

I never said it was bad nor did i say it wouldn't work but I'm going to leave it with this. Like I already said you are a respected member of this community and i respect your opinion on things and you are right maybe i'm making a to big fuss about it and I now know the pros and cons of using both techniques (I am just someone who doesn't easily do A just because someone said A is better). Anyway thanks for clearing this out!

 

does not seem to go hand-in-hand with

 

And what amazes me even more is why if this is so wrong it is used in the Zend framework?

 

And I'm still not so sure about that whole "respected member of the community" thing, but anyways, not blindly taking someone's word for it is a good thing.  Always find out why! Always compare!  There are some things that are generally a bad idea no matter what.  There are also some things that are generally good no matter what.  But between those two things is a mile-wide gray zone where everything else falls, because what may work for one situation/setup/whatever may not work for another, etc..

 

Which is why I question things like that, even if it's apparently included in things like the Zend Framework.  I think the odds of me being smarter than everyone involved in the Zend Framework, not to mention everybody who uses it, are pretty damn slim.  But I don't see why it should be there.  At least, not for this purpose.  If someone can jump in and explain it, that would be awesome.

 

[Philip]

You know, I think a ternary would work just fine

 

I never said it was bad nor did i say it wouldn't work but I'm going to leave it with this. Like I already said you are a respected member of this community and i respect your opinion on things and you are right maybe i'm making a to big fuss about it and I now know the pros and cons of using both techniques (I am just someone who doesn't easily do A just because someone said A is better). Anyway thanks for clearing this out!

 

I think CV gave the same point I was trying to make but couldn't put it into the correct words. I'll leave it at that.

 

I will however, add one piece of advice that he did mention. Just because Zend does it, doesn't mean it is the best/right way to do it for you. As a developer you should be looking for the best (and typically the easiest) way to implement an idea for your specific setup (or as case might be, for a range of setups.) This means opening your eyes a bit, and I admit I had never thought of having a fall back field like you suggested. Did I learn from it? Yes. Did you learn from it? I sure hope so.

[ignace]

I am just someone who doesn't easily do A just because someone said A is better

 

does not seem to go hand-in-hand with

 

And what amazes me even more is why if this is so wrong it is used in the Zend framework?

 

At first I couldn't see the added value of a framework (to much you don't need, mostly untested, thousand pages of configuration, ..). Then someone said that I am always using a framework wether or not it is visually there. Then i started using Zend first as a test project and afterwards i started using it in production environments and now I am among the believers of frameworks and Zend and it's methods, as my posts in this thread clearly states.