GeorgeInFlorida;11016733 wrote:
<option value="01">Pro photographer</option>
[/qoute]
I would however drop the 0 in front of numbers 1-9. They'd only make sense in the following cases
1. Formatting when being read by humans. Since they won't be shown to humans, this is not the case
2. Storing things as strings, that is working with numeric characters, or numeric strings if you will. This should be stored as some numeric data type, or an unsigned integer to be more specific, so this isn't the case either.
3. Sometimes used for times, as in 03:35
It doesn't really make any difference in the end, since you should be casting these to integers server side anyway, before you insert the values into the database.
if (isset($_POST['profile_type']))
{
# If $_POST['profile_type'] is ... then $pt will be ...
# 01 => 1
# hello => 0
# 15 => 15
$pt = (int) $_POST['profile_type'];
}
Finally, I'd advice against storing these values as enums. Instead, use a separate table to hold those values. As such, you'd be storing an integer in the user table and keep the profile types stored in a separate table as id / profile description pairs
CREATE TABLE user (
id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
username VARCHAR(20),
first_name VARCHAR(20),
email VARCHAR(50),
profile_type TINYINT UNSIGNED,
FOREIGN KEY (profile_type) REFERENCES profile_type(id)
);
CREATE TABLE profile_type (
id TINYINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
name VARCHAR(30),
);
This approach has some benefits over the other one if you ever want to add a new profile type. You won't have to alter the user table to change your enum values. You'd simply add a new row to the profile_type table. This also means that you won't have to rebuild the profile_type index in the user table. At least I'm guessing you should have an index on that field. The foreign key in my solution automatically creates an index for it.
But perhaps more importantly, you won't have to hard code your select box values as you've done now.
# My pretend database interface. Get stuff from the db as you usually do
$profiles = $db->getResult("SELECT id, name FROM profile_type");
$select = '<select name="profile_type">';
foreach ($profiles as $p)
{
$select .= sprintf('%s<option value="%d"%s>%s</option>',
"\n\t" /* just used for formatting of html code */,
$p['id'],
$p['id'] == $user->getProfileId() ? ' selected' : '',
$p['name']
);
}
As for replacing eregi_replace with preg_replace, the proces is usually rather simple. preg patterns need a starting and ending delimiter, which according to the php manual can be any non-alphanumeric, non-backslash, non-whitespace character. After the ending delimiter you can optioanlly include pattern matching options, which in this case should include i for case insenitive match, this
$pattern = '#your_old_pattern_here#i';
But be adviced that I do not know if ereg supported patterns which preg can't handle, so the actual process of converting a pattern may be more involved. However, I've come to believe (for no real good reason) that this process always works from ereg to preg, but it wouldn't always work in the reverse.
