Forum Moderators: open
The array has about 10,000 elements. Each element has three sets of data. I want to use the array to 1) create a number of identical dropdowns with one option for each element 2) retreive the data for each element when that option is selected.
As far as I can see it, I have the following options.
a) Create an Object() with 10,000 elements. Each element is an array with three elements. Use for(## in ##) to document.write() <options>.
b) Create two arrays. One holds the 10,000 "IDs" (used to dynamically document.write() <options>). The other is an associative array with data. Each element in the array being an array itself.
c) Create an Object() with 10,000 elements. Each element will hold the data separated by commas. Use for(## in ##) to document.write() <options>. Use split() when using the data.
d) Create two arrays. One holds the 10,000 "IDs" (used to dynamically document.write() <options>). The other holds the data separated by commas. Use split() when using the data.
What would be the most efficient way of handling this? Speed is the most important factor.
And no, I can't use a server side solution. I would if I could
I tried a sample run through with this:
<script>
id_array = new Array();
open_select = '<select>';
close_select = '</select>';
open_option = '<option id="';
close_option = '</option>';
li_items = open_select;
for ( i=0; i< 10000; i++)
{
id_array[i] = '_' + i;
li_items += open_option + id_array[i] + '">' + id_array[i] + close_option;
}
li_items += close_select;
document.write(li_items);
</script>
That's about 1/4 of the functionality you described, maybe 1/6, and that took about 17 seconds to just create the page, and that's with only a single document.write, on a fast computer, if you had multiple d.writes that would obviously increase the time dramatically. And that's not including the much larger data arrays you're describing, it looks like you'd be somewhere around 1 minute to generate the page on a very fast computer, several on a slower one.
It's not clear to me what you are actually setting out to do, if you don't have to write out all the options, it's radically faster of course. If you can't use server side scripting then where is the data array data coming from, you're not typing it in I assume?
You have no idea what type of computing resources are available to each surfer. Offloading all of the computation to their browsers may put them over the edge.
What does it mean that you "can't use a server side solution?" Are you just referring just to server side scripting (PHP, ASP, etc.), or cannot you also not use a multi-page (or iFrame) selection process.
server side solution
The data is extracted from a MySQL database using PHP. But to actually write all that data to the browser (generating the dropdowns server side) will make the page a couple megs :(
Even with just sending the arrays to the browser makes up about 200Kb.
To give you some more insight into what it's doing.... It's a quickorder form. Just under 10,000 items. For each item I have the item ID, price, short description, and available quantity.
The item IDs are displayed in the dropdowns. When you select an item it outputs the description, price, qty next to it. They form has five lines with the ability of inserting more lines (using JavaScript).
But if all 10,000 select/option items need to be physically on the page on first load, even just using javascript, you're still dealing with a huge amount of page rendering time no matter what, that would be completely unacceptable as far as I can see, I draw the line at around 15 seconds, over dialup, that would go well over that.
I've heard of flash being used for this kind of thing, it can do live interaction with the backend programming, but I've never done it, but it sort of sounds like something that might do it for you in this case, unless you're like me and never use flash.
If so, why don't they just enter it in a form text field and hit enter?
For example searching for ID, or for part of the description.
It might also be a good idea to offer people the choice of selecting a desired price-range to cut down the number of displayed items.
My bank's credit card reward program offers all these choices for selecting which product to claim against points.
Basically, look at it this way: it's a quickorder form where they enter all the item IDs for what they want to order, then add it all at once to the cart. They are not interested in browsing, they just want to enter the item ID, and the qty, and be done. But, they want to make sure the desired qty is available, and get a brief description to confirm that they entered the correct item ID... and price to calculate how much it will be before submitting the form.
There are other browsing functionalities... but that's separate from the quickorder form.
Give them a page with no list at all. It has a form for the user to enter as many IDs as they want.
The form gets submitted.
A confirmation page is displayed with only the required IDs with full descriptions and prices.
The user clicks a button on the confirmation page to place the order.
The user should also be able to cancel from the confirmation page, or delete/edit one or more product IDs and then reconfirm.
Does all that make sense?
There is a whole order system with different ways of order, searches, confirmations, etc, etc. But this is a sheet that allows them to real quickly place an order for the few items they have. They can currently do what you're describing -- enter any number of IDs, submit, get a confirmation screen.
But these guys place tons of orders. And sometimes they mistype an ID or so. Or, they don't get notified about available quantity till the next page. Some of them are like "ok, I have planned on spending $2000 on the order this week... let's see what that will get me", which is why all that has to be on the first page where the ID entry takes place.
If anything I can get rid of the dropdowns. But I still need to load all the other data and parse through it.
Still... getting rid of the dropdowns saves an immense amount of JavaScript rendering. It also makes the search much faster. It's 300Kb less for the JavaScript to render.
So, that puts me at:
a) Create one Array(). Each element in the Array() is an Array() itself (holding price, description, quantity).
b) Create one Array(). Each element in the Array() is a comma-separated list of data. I'll have to use split() to extract the different pieces of data (which isn't necessarily a big deal, since I always use all three together).
So which one of the two do you think will perform best? Which one would you use, and why?
With that method you would use parallel arrays, putting your available quantity in one array that is always loaded with the page and the descriptions in a second array located in the external javascript.
The server would track whether a given session has retrieved the description array yet or not. Once it has, then future requests for the array from the same session would just return an HTTP 304 status.
The primary benefit of doing it this way is that if they visit the page more than once, subsequent page loads will go faster.
Also, if you do utilize ANY external javascript files, then the other recommendation I have is to detect whether or not the external javascript is loaded or not. You can do this by setting a variable to indicate whether or not the external file has finished loading. In the head of your page, initialize the var to false and add a function that can be called to set the variable to true. Add a call to this function at the bottom of your external javascript file. Then, on your functions that try to display descriptions and prices for entered IDs, check to make sure all is loaded. This is all to prevent javascript errors that will inevitably occur because the user starts doing their work before everything is loaded.
And no, I can't use a server side solution. I would if I could
Do you have the option of using something besides JS? If it was allowed you could write a program in C or VB (if your short on time). The users could download a compiled program that just pulls the data from the database.
So, that puts me at:a) Create one Array(). Each element in the Array() is an Array() itself (holding price, description, quantity).
b) Create one Array(). Each element in the Array() is a comma-separated list of data. I'll have to use split() to extract the different pieces of data (which isn't necessarily a big deal, since I always use all three together).
It would take a guru like you only a couple of minutes to build two test pages, one for each method (you don't have to worry about making the output pretty at this stage). Time them both, and see which finishes fastest! That's the only way to get a genuine answer to your question.
I also like the idea of using .js files... it sounds to me like your customers are regulars, so having the arrays external means the customers don't have to download the 200kb every time. I suggest you split the data across, say, 10 .js files of 20kb each, so that if one product changes they only need to re-download 1/10th of the data.
Finally, as well as using the hourglass cursor, give them some text: "Building product list, please wait a moment".
var prod = new product_info('timmy', 2, 5, $1000);
function product_info(name, number, quantity, price)
{
this.name = name;
this.number = number;
this.quantity = quantity;
this.price = price;
}
document.write(prod[i].name);
document.write(prod[i].number);
.
.
.
That said, I think there is a work-around that is the best opf both worlds. This is a perfect case for a RPC. Have a text box for entering the id and on either onblur or onchange, with a check for the length of a valid id, call a function that dynamically creates a <script> element with the id in the querystring and appendChilds it to the <head>.
Then have your server-side stuff just output a function into that .js that updates the description, price etc. This can actually be pretty snappy, and this is a case where I thik the performance of that small call to the server will be MUCH more responsive on the client-side.
Well, it was requested by the user...
> not having the full list
They want to be able to navigate up and down in the list... A call to the server is slower than getting the data from a JavaScript array.
I thought you said they know the id, and can just type it in, but you just didn't want them to wait for a full page load to see the results. This would still require a round-trip, but it's as small of a round-trip as you can make, and no page refresh. Sometimes I have really found that sort of thing to perfom much better than dealing with passing silly large datasets around, and trying to crunch them in .js, and dealing with the intial slow download.
Of coure, if (you would know best) it really needs to be all passed to the client (such as your syaing they want to be able to go up and down the list,via arrows or whatever), then the already made suggestions about caching as much as you can in different files is your best option. I am willing to bet actual time on these roundtrips is still going to take longer than just doing a small RPC (barring the whole manual list navigation thing), but I guess percieved time is all that matters, and that is one you'll always have to just test for.
Good luck, either way.
Wait, so are you doing a text-box that sets the current select on the list, then, or are they supposed to pull-down a 10,00 item select and find the one they want (as IE does a crappy "find in select" natively)?
