...

View Full Version : Problems with <select> tags - one is huge, the other one is a chained



abduraooft
11-15-2012, 04:39 PM
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.

minder
11-15-2012, 08:26 PM
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.

VIPStephan
11-15-2012, 10:18 PM
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.

minder
11-15-2012, 10:32 PM
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.

VIPStephan
11-15-2012, 11:53 PM
Are you able to read? Then read again what’s even printed in bold:

[The forms] should function even if there's no javascript.

And by the way: one doesn’t exclude the other.

minder
11-16-2012, 04:55 AM
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.

abduraooft
11-17-2012, 03:09 PM
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.

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

minder
11-17-2012, 10:12 PM
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.

tangoforce
11-17-2012, 11:21 PM
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.

firepages
11-18-2012, 09:43 AM
.....

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.

abduraooft
11-19-2012, 11:02 AM
There's only one query.

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

Showing rows 0 - 351 (352 total, Query took 0.0056 sec)
which is fine.

So, the delay might be caused by the DOM to create all those options in the list. Hope I don't have to worry about the server overheads.

PS: fyi: I'm using the jquery plugin chosen (http://harvesthq.github.com/chosen/), to display the dropdown, which is awesome!

minder
11-19-2012, 11:15 AM
Well there's one source of your delay - jquery!!!

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


make the forms in such a way that they should function even if there's no javascript.

No javascript, then NO JQUERY either!!

abduraooft
11-19-2012, 11:29 AM
btw: why are you using jquery (which is javascript) since you said in your op

I'm after http://en.wikipedia.org/wiki/Progressive_enhancement :).

minder
11-19-2012, 12:56 PM
I'm after http://en.wikipedia.org/wiki/Progressive_enhancement :).

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


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.

minder
11-19-2012, 10:10 PM
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.



EZ Archive Ads Plugin for vBulletin Copyright 2006 Computer Help Forum