Arranging <option> as last in <select> [SOLVED]

PHP programming forum. Ask questions or help people concerning PHP code. Don't understand a function? Need help implementing a class? Don't understand a class? Here is where to ask. Remember to do your homework!

Moderator: General Moderators

Post Reply
User avatar
aceconcepts
DevNet Resident
Posts: 1424
Joined: Mon Feb 06, 2006 11:26 am
Location: London

Arranging <option> as last in <select> [SOLVED]

Post by aceconcepts »

Hi,

I have a <select> element that is populated with values from a MySQL database.

The list may consist of values such as "Mr, Mrs, Other, Dr".

My question is: how can I arrange the list so that "Other" displays last even if it is not last in the database table?

I dont really want to have to put an additional <option> after my loop.

Thanks.
Last edited by aceconcepts on Mon Sep 24, 2007 11:19 am, edited 1 time in total.
User avatar
aaronhall
DevNet Resident
Posts: 1040
Joined: Tue Aug 13, 2002 5:10 pm
Location: Back in Phoenix, missing the microbrews
Contact:

Post by aaronhall »

If you're not already ordering the results, try adding a separate int 'order' column to the table and make the cell corresponding to "Other" a higher value than the rest. Append "ORDER BY `order`" to your query, but not before a LIMIT clause.

You'd normally not have these values stored in a database anyway unless you plan on changing them frequently.
User avatar
Zoxive
Forum Regular
Posts: 974
Joined: Fri Apr 01, 2005 4:37 pm
Location: Bay City, Michigan

Post by Zoxive »

Maybe a simple if Statement in your loop when your pulling out of the database.
User avatar
onion2k
Jedi Mod
Posts: 5263
Joined: Tue Dec 21, 2004 5:03 pm
Location: usrlab.com

Post by onion2k »

aaronhall wrote:You'd normally not have these values stored in a database anyway unless you plan on changing them frequently.
I don't agree with that. Even if they're not changed often the database is still the best place to keep them.
User avatar
aceconcepts
DevNet Resident
Posts: 1424
Joined: Mon Feb 06, 2006 11:26 am
Location: London

Post by aceconcepts »

Thanks for all the ideas.

I do like the idea of an IF statment in the loop...nice.

P.s. I like to keep lists like this in a database for the pure fact that its nice and straightforward, easy to amend/add new values.

Anyway, thanks for the posts.
User avatar
aaronhall
DevNet Resident
Posts: 1040
Joined: Tue Aug 13, 2002 5:10 pm
Location: Back in Phoenix, missing the microbrews
Contact:

Post by aaronhall »

onion2k wrote:
aaronhall wrote:You'd normally not have these values stored in a database anyway unless you plan on changing them frequently.
I don't agree with that. Even if they're not changed often the database is still the best place to keep them.
It probably depends on how static the information is, and if it's worth an extra query to the database to pull it out. Unless you're building a front end to manage that table, it's probably easier editing template files than it is incurring the extra overhead/code to be able to stick it into a table. It always depends on what's happening with that data afterwards anyway, so I was quick to classify this as non-database-worthy. I'm also thinking of the extra overhead to retrieve this info later on if it's associated with another table in the database.
User avatar
aceconcepts
DevNet Resident
Posts: 1424
Joined: Mon Feb 06, 2006 11:26 am
Location: London

Post by aceconcepts »

I know what you're saying about the "overhead". Sometimes I think is it really worth it!!!

I guess for its just normal practice or habit :D
User avatar
aaronhall
DevNet Resident
Posts: 1040
Joined: Tue Aug 13, 2002 5:10 pm
Location: Back in Phoenix, missing the microbrews
Contact:

Post by aaronhall »

As a generalization, if it makes life easier for the programmer, it almost always makes life more difficult for the computer running the code. :)
User avatar
onion2k
Jedi Mod
Posts: 5263
Joined: Tue Dec 21, 2004 5:03 pm
Location: usrlab.com

Post by onion2k »

aaronhall wrote:
onion2k wrote:
aaronhall wrote:You'd normally not have these values stored in a database anyway unless you plan on changing them frequently.
I don't agree with that. Even if they're not changed often the database is still the best place to keep them.
It probably depends on how static the information is, and if it's worth an extra query to the database to pull it out. Unless you're building a front end to manage that table, it's probably easier editing template files than it is incurring the extra overhead/code to be able to stick it into a table. It always depends on what's happening with that data afterwards anyway, so I was quick to classify this as non-database-worthy. I'm also thinking of the extra overhead to retrieve this info later on if it's associated with another table in the database.
You've missed the main advantage of keeping things in the database. If you don't put something like the user titles into the database then every single time you output the user information (order receipts, CSV dumps of customers, emails to them, etc) you'll have to include your array of titles and convert the ID in the database into the text. If they're in the database they can be pulled out with an inner join. Coupled with some SQL concatenation you can build the user's real name as a single field. If you're using something a little cleverer than MySQL you can even create a view that has the users display name as a column. The advantage of keeping information in the database is so that the database to make use of it, it's got nothing to do with how easy it is to maintain really.
User avatar
aaronhall
DevNet Resident
Posts: 1040
Joined: Tue Aug 13, 2002 5:10 pm
Location: Back in Phoenix, missing the microbrews
Contact:

Post by aaronhall »

I'm only arguing against keeping the list in a separate table, for exactly the reason you cited (inner joins are expensive). For a small, unchanging list like that, a SET field would be a lot more efficient even it if is a little more difficult maintain. This only requires maintaining the list in the add and edit forms, and spares you the extra table join every time you want to get a person's name.
Post Reply