Arranging <option> as last in <select> [SOLVED]
Moderator: General Moderators
- aceconcepts
- DevNet Resident
- Posts: 1424
- Joined: Mon Feb 06, 2006 11:26 am
- Location: London
Arranging <option> as last in <select> [SOLVED]
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.
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.
- aaronhall
- DevNet Resident
- Posts: 1040
- Joined: Tue Aug 13, 2002 5:10 pm
- Location: Back in Phoenix, missing the microbrews
- Contact:
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.
You'd normally not have these values stored in a database anyway unless you plan on changing them frequently.
- aceconcepts
- DevNet Resident
- Posts: 1424
- Joined: Mon Feb 06, 2006 11:26 am
- Location: London
- aaronhall
- DevNet Resident
- Posts: 1040
- Joined: Tue Aug 13, 2002 5:10 pm
- Location: Back in Phoenix, missing the microbrews
- Contact:
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.onion2k wrote:I don't agree with that. Even if they're not changed often the database is still the best place to keep them.aaronhall wrote:You'd normally not have these values stored in a database anyway unless you plan on changing them frequently.
- aceconcepts
- DevNet Resident
- Posts: 1424
- Joined: Mon Feb 06, 2006 11:26 am
- Location: London
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.aaronhall wrote: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.onion2k wrote:I don't agree with that. Even if they're not changed often the database is still the best place to keep them.aaronhall wrote:You'd normally not have these values stored in a database anyway unless you plan on changing them frequently.
- aaronhall
- DevNet Resident
- Posts: 1040
- Joined: Tue Aug 13, 2002 5:10 pm
- Location: Back in Phoenix, missing the microbrews
- Contact:
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.