Checked?

PHP
1

I have a variable in a mysql database (amenities) which holds selected values from a checkbox
below is when I echo the variable to the screen,


    [amenities] => 2,3

The numbers (separated by a ,) are values of a bunch of checkboxes



<input type="checkbox" name="amenities[]" value="0" >Washer/Dryer<br>
<input type="checkbox" name="amenities[]" value="1" >Kitchen Appliances<br>
<input type="checkbox" name="amenities[]" value="2" >Patio<br>
<input type="checkbox" name="amenities[]" value="3" >BBQ Grill<br>
<input type="checkbox" name="amenities[]" value="4" >Balcony<br>

how do I make it so that if the value of the checkbox is in the list, the box will be checked?

Thanks…

2

Instead of saving the selected values as plain text in the db, I would suggest to store them as a serialised array, since it’s going to be more flexible. When you retrieve them, you can [URL=“http://www.php.net/manual/en/function.unserialize.php”]unserialise them, and [URL=“http://php.net/manual/en/function.in-array.php”]search in them for the value of a specific checkbox. If it’s present, you can mark it as selected.

3

Assuming your variable is an array, you could use in_array


if(in_array(0,$amenities)) echo "checked";
4

thanks

5

Taken from the PHP comments for in_array:

Be aware of oddities when dealing with 0 (zero) values in an array…

This script:

<?php
$array = array('testing',0,'name');
var_dump($array);
//this will return true
var_dump(in_array('foo', $array));
//this will return false
var_dump(in_array('foo', $array, TRUE));
?>

It seems in non strict mode, the 0 value in the array is evaluating to boolean FALSE and in_array returns TRUE. Use strict mode to work around this peculiarity.
This only seems to occur when there is an integer 0 in the array. A string ‘0’ will return FALSE for the first test above (at least in 5.2.6).

6

ok, going to make it a serialized array, I have a few questions though
when I go like this


        $amenities = $_POST['amenities'];
        $amenities = serialize($amenities);
        echo $amenities;

I get

a:2:{i:0;s:1:“0”;i:1;s:1:“1”;}

But when I echo the original array


echo "<pre>"; print_r ($_POST); echo "</pre>";

I get
[amenities] => Array
(
[0] => 0
[1] => 1
)

why is the serialized array show a string type
http://php.net/manual/en/function.serialize.php
shouldnt it be an integer? (the values can only be integers; 0, 1, 2, 3, and 4)

Also, how do I store the serialized array into the database (datatype?)

Thanks…

7

It isn’t really a string type more like a string representation of your array. When you call unserialize($amenities) you will see you get back the exact array you dumped using print_r($_POST[‘amentities’])

To put that into perspective:

<?php
$amentities = array(0, 1, 2);
echo '<pre>'; print_r($amentities); echo '</pre>';
$amentities = serialize($amentities);
echo $amentities;
$amentities = unserialize($amentities);
echo '<pre>'; print_r($amentities); echo '</pre>';
8

Surprising that everyone has failed to mention that serializing data and stuffing a representation of multiple values into a single column breaks first normal form. Generally speaking you should not be serializing data and tossing it into a single column. What happens when you want to filter entities by specific amenities? I will tell you what if your not the person who has to deal with that problem the person who does will curse your incompetence. There are only very rare cases that multiple values should be stuffed into a single column and even those instances would be debatable. Read up on proper normalization so you don’t end up like one of the many posters on this very forum dealing with a problem later down the road that is the result of not properly normalizing the database. If you need some help I’m sure people over in the database section of the forum will set you straight. Especially if you believe first normal form is insignificant.

Instead of saving the selected values as plain text in the db, I would suggest to store them as a serialised array, since it’s going to be more flexible. When you retrieve them, you can unserialise them, and search in them for the value of a specific checkbox. If it’s present, you can mark it as selected.

Never mind… I see where you got that idea from. Completely ignore this. On the contrary serialized data in a relational database schema is a nightmare to manage. Especially when it comes to filtering, aggregating, and sorting by segments data stored within the serialized array that would be better off represented with 1:m or m:n relationship.

In this specific case it would seem appropriate to use a m:n relationship. One table for the amenities and another to relate an amenity to another table (entity). I’ve dealed with my fair share of real estate system in all cases this is how the data is stored in the simplest forms – not serialized arrays.

listing

  • id

listing_amenity

  • listing_id
  • amenity_id

amenity

  • id
  • name

You could even use surrogate key of the amenity table if that is what floats your boat but I do prefer using surrogate keys for many reasons. This architecture is now flexible enough to filter, sort, and group by specific amenities. Where as serializing crap and throwing it into a single column will be a gigantic clusterf**k down the road in regards to performance, accuracy, flexibility, and maintainability.

I know there are always exceptions but in general never serialize data and toss it into a single column. Especially, when you are just starting out. Once you know some of rules and what not than perhaps in some cases where a lot of magic is needed it is “ok”… ish.

Also, in this day and age if you find yourself working a lot with key/value pairs than perhaps a relational database is not the best option. Perhaps a NoSQL storage facility is better like MongoDB. Something to consider.

9

Not all that surprising really… there are times where normalizing your data, doesn’t exactly make sense. What if I don’t need to sort/search my information? From his array layout, sorting/searching it would be meaningless from a database standpoint anyway.

Think of it this way, let’s say I have a site that allows you to customize a few things: Layout, Thread Display, Searches per Page, etc. Why would I want to store that in a separate table? I don’t need to search it, and when I likely need to use it, I’ll need more than just one of the values, so I can’t just grab the one I want. Storing that either serialized or in a delimited string makes perfect sense.

10

I didn’t think about that before, better have a separate table for the amenities, cause ill eventually want to sort by them

11

You never know what will be needed in the future. Best to plan ahead.

I work with Drupal quite of bit and yes the system does promote mass serialization of these things. I don’t particularly like it but see why it is being done given the complexity of the data and flexibility the system offers. Though that isn’t to say that mass serialization doesn’t lead to major problems. Which is probably why Drupal 8 uses YAML based file storage for those cases instead of tossing that type of data in the db like it us to in versions prior.

There isn’t any reason though why this simple data can’t be stored in a separate table using proper normalization. It is no where as near as complex as many of Drupal data structures that get stuffed in a single database column using serialization.