Problems with <select> tags - one is huge, the other one is a chained
Hi all,
I'm facing two issues in designing two forms. The main cause of my problem is the intention to make the forms in such a way that they should function even if there's no javascript.
One form has a <select> element with 300+ <option>s in it. The values are stored in DB and it's being populated by a PHP loop. This huge list affects the speed of display of form. I'm also afraid of the system overhead to generate this huge list each time when a user tries to access this form.
I can use Ajax and transform a text input to a dhtml list, to search and list matched entries from db when the user types something in it.
The other one has a chained <select>. The first list has 10+ entries and the second list also has 10+ entries corresponding to each entry in first list.
What's "best" and user-friendly way to tackle these "issues"? Please share your suggestions/opinions/practices.
Thanks.
__________________
Quote:
The Dream is not what you see in sleep; Dream is the thing which doesn't let you sleep. --(Dr. APJ. Abdul Kalam)
I'm also afraid of the system overhead to generate this huge list each time when a user tries to access this form.
One option is to get the <select> options only once from the db and store them in a session array. Getting data from the array each time it's needed will be quicker than getting it from the db.
As to the subsequent select options I'd say have a submit button for each so that the user chooses an option, sends the form, and PHP returns the same form with a new select with options that are based on the first selection.
As to the subsequent select options I'd say have a submit button for each so that the user chooses an option, sends the form, and PHP returns the same form with a new select with options that are based on the first selection.
I wouldn't use a submit button for the chained selects because it results in page refreshes. A more user friendly experience for the user would be to use ajax to get the options for the "child" selects and so refresh and populate the "child" selects without page refreshes.
If you haven't got javascript available then it's a no-brainer that you need a button/link of some type to submit a hierarchy of selected options to the same web page. At the top of the page you get from the db the options according to the already selected options for each select (or default options for the first select if none selected) and output them in the html. You don't have any other choices in principle afaik if you need to support browsers without javascript.
Once a selection has been made in each chained select, do your your normal processing for the form data.
One option is to get the <select> options only once from the db and store them in a session array. Getting data from the array each time it's needed will be quicker than getting it from the db.
Values saved in session for one user won't be available for another one - which means writing and reading a lot of data to/from the session may make more overheads.
Edit:I request a mod to move this to PHP section
I'm thinking about to make and synchronise an xml file from DB, with all option values. Can the system get any advantage when populating the <select> list from this xml file, when compared to the DB fetch operation?
Thanks
__________________
Quote:
The Dream is not what you see in sleep; Dream is the thing which doesn't let you sleep. --(Dr. APJ. Abdul Kalam)
Values saved in session for one user won't be available for another one
Of course it won't.
But I was thinking of the situation where a user might go to your page containing the form whose select lists are populated from the db. If the user then goes to another page on your web site and then returns to the page containing the form, the page will have to make another call to the db to retrieve the 300+ options instead of getting them from the session array of options.
Regarding using an xml file, I'm pretty sure it would be faster than using db but an xml file, being text file, will most probably be less secure than a db.
One form has a <select> element with 300+ <option>s in it. The values are stored in DB and it's being populated by a PHP loop. This huge list affects the speed of display of form. I'm also afraid of the system overhead to generate this huge list each time when a user tries to access this form.
It shouldn't really..
Are you running queries in each iteration of that loop? - I ask because moons ago I had a script that would select the next item from the database in a loop and then add that info into the html. It got to the point where it would take in excess of 30 seconds on my localhost (imagine it on a live site with a few users).
Skip ahead a few months and I found mysql's logging. When I looked at it I realised why that script was so slow - over 300 queries. Naturally I tidied this up down to one query with a couple of joins and it ran in an instant. The same number of rows but smarter and quicker than previously.
Thats why I'm asking about your setup. It's only 300 loops so shouldn't take more than a few milliseconds on a 2+GHz processor.
//Please don't use this for your form processing:
if (isset($_POST['submit']))
//Internet explorer has a bug and does not always send the submit value.
I'm thinking about to make and synchronise an xml file from DB, with all option values. Can the system get any advantage when populating the <select> list from this xml file, when compared to the DB fetch operation?
Thanks
Tango is right here, if the query is slowing the process down then there is something wrong with the query or how the data is called/stored.
Using an existing DB connection will be far faster than the overhead of loading the XML and parsing it, if you are going to store in a flat file then a serialized PHP array will be much faster to parse, I would still go the DB route though.
MVC is the current buzz in web application architectures. It comes from event-driven desktop application design and doesn't fit into web application design very well. But luckily nobody really knows what MVC means, so we can call our presentation layer separation mechanism MVC and move on. (Rasmus Lerdorf)
SQL query: SELECT O.org_id, O.org_name, O.short_name, O.website, O.email, O.logo_path, date_format( O.reg_date, '%d-%b-%Y' ) formatted_date, O.user_count, O.org_status
FROM organisation AS O
WHERE O.org_status != 'D'
ORDER BY O.org_name
and when I execute it via phpmyAdmin's query tab, it shows
You don't need jquery (and its overheads) to create the select lists at all.
You simply get php tp query the database for the options data, then loop through the result set, in php, to create the html for the select and its options, still on the server, before sending the html including the html for the select and the 300+ options back to the user's browser.
If you get rid of the jquery "layer" in the creation of select and its options, I'm sure your page will load much faster.
btw: why are you using jquery (which is javascript) since you said in your op
Quote:
make the forms in such a way that they should function even if there's no javascript.
That's fine but when you don't need javascript/jquery at all for what you are doing, I just don't see the point of introducing an extra overhead after you said
Quote:
I'm also afraid of the system overhead to generate this huge list each time when a user tries to access this form.
and then coming to a forum asking how things can be done better
The answer is simple, get rid of the jquery and just do it all server side and you will have less overheads and your page will load much faster.
Make the page work first doing it all server side, since you don't need javascript/jquery at all, and then add the javascript functionality if you want to. Not the other way around.
Before you post, read our: 
.
