Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Results 1 to 15 of 15
  1. #1
    Supreme Master coder! abduraooft's Avatar
    Join Date
    Mar 2007
    Location
    N/A
    Posts
    14,865
    Thanks
    160
    Thanked 2,224 Times in 2,211 Posts

    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.

    1. 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.
    2. 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.
    The Dream is not what you see in sleep; Dream is the thing which doesn't let you sleep. --(Dr. APJ. Abdul Kalam)

  • #2
    Banned
    Join Date
    Oct 2012
    Posts
    81
    Thanks
    0
    Thanked 4 Times in 4 Posts
    Quote Originally Posted by abduraooft View Post
    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.
    Last edited by minder; 11-15-2012 at 08:46 PM.

  • #3
    The fat guy next door VIPStephan's Avatar
    Join Date
    Jan 2006
    Location
    Halle (Saale), Germany
    Posts
    8,927
    Thanks
    6
    Thanked 1,040 Times in 1,013 Posts
    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.

  • #4
    Banned
    Join Date
    Oct 2012
    Posts
    81
    Thanks
    0
    Thanked 4 Times in 4 Posts
    Quote Originally Posted by VIPStephan View Post
    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.

  • #5
    The fat guy next door VIPStephan's Avatar
    Join Date
    Jan 2006
    Location
    Halle (Saale), Germany
    Posts
    8,927
    Thanks
    6
    Thanked 1,040 Times in 1,013 Posts
    Are you able to read? Then read again what’s even printed in bold:
    Quote Originally Posted by abduraooft View Post
    [The forms] should function even if there's no javascript.
    And by the way: one doesn’t exclude the other.

  • #6
    Banned
    Join Date
    Oct 2012
    Posts
    81
    Thanks
    0
    Thanked 4 Times in 4 Posts
    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.

  • #7
    Supreme Master coder! abduraooft's Avatar
    Join Date
    Mar 2007
    Location
    N/A
    Posts
    14,865
    Thanks
    160
    Thanked 2,224 Times in 2,211 Posts
    Quote Originally Posted by minder View Post
    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
    Last edited by abduraooft; 11-17-2012 at 03:19 PM.
    The Dream is not what you see in sleep; Dream is the thing which doesn't let you sleep. --(Dr. APJ. Abdul Kalam)

  • #8
    Banned
    Join Date
    Oct 2012
    Posts
    81
    Thanks
    0
    Thanked 4 Times in 4 Posts
    Quote Originally Posted by abduraooft View Post
    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.

  • #9
    Senior Coder
    Join Date
    Feb 2011
    Location
    Your Monitor
    Posts
    4,474
    Thanks
    63
    Thanked 537 Times in 524 Posts
    Quote Originally Posted by abduraooft View Post
    1. 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.
    I can't really think of anything to write here now...

  • #10
    Super Moderator
    Join Date
    May 2002
    Location
    Perth Australia
    Posts
    4,108
    Thanks
    11
    Thanked 101 Times in 99 Posts
    Quote Originally Posted by abduraooft View Post
    .....

    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.
    resistance is...

    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)

  • #11
    Supreme Master coder! abduraooft's Avatar
    Join Date
    Mar 2007
    Location
    N/A
    Posts
    14,865
    Thanks
    160
    Thanked 2,224 Times in 2,211 Posts
    There's only one query.
    Code:
    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, to display the dropdown, which is awesome!
    The Dream is not what you see in sleep; Dream is the thing which doesn't let you sleep. --(Dr. APJ. Abdul Kalam)

  • #12
    Banned
    Join Date
    Oct 2012
    Posts
    81
    Thanks
    0
    Thanked 4 Times in 4 Posts
    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!!

  • #13
    Supreme Master coder! abduraooft's Avatar
    Join Date
    Mar 2007
    Location
    N/A
    Posts
    14,865
    Thanks
    160
    Thanked 2,224 Times in 2,211 Posts
    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 .
    The Dream is not what you see in sleep; Dream is the thing which doesn't let you sleep. --(Dr. APJ. Abdul Kalam)

  • #14
    Banned
    Join Date
    Oct 2012
    Posts
    81
    Thanks
    0
    Thanked 4 Times in 4 Posts
    Quote Originally Posted by abduraooft View Post
    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.
    Last edited by minder; 11-19-2012 at 12:58 PM.

  • #15
    Banned
    Join Date
    Oct 2012
    Posts
    81
    Thanks
    0
    Thanked 4 Times in 4 Posts
    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.


  •  

    Posting Permissions

    • You may not post new threads
    • You may not post replies
    • You may not post attachments
    • You may not edit your posts
    •