Need Design Advice - Javascript Vs. Ajax, Etc.

[WebNerd]

I could use some advice about a design decision I need to make. First, let me explain the issue. I have a web report that requires the user to pick one or more items on which to report. There are nearly 600 items. The items are currently displayed by name and identification number. The list is not as bad as it sounds because the users know exactly what items they want and can search for them. The problem is that the items are sorted by name. Some users would like to be able to sort the items by ID number. I can think of several way to do this, but I'm not sure which is best. If the user changes the sort order, I'd like to keep track of the items they've already selected so that they don't have to select them again.The first way is to just create another page. This seems like it would be slower and less efficient. I'd have to post the form to track if any items were already selected before sending back the resorted list.The second way would be to use Javascript and DHTML. I haven't done anything like this before, but I think I know what to do. I could either have two lists, with one or the other hidden, or I could use Javascript to rebuild the list if the user changes the sort order. The downside to this might be that the code for the page could be really huge.The third way is to use AJAX. I could retrieve the sorted list from the server instead of having all of that Javascript code to store the list. I cache much of the data on the server, so the retrieval would be quick. I have to confess that I'm sort of excited about this option because I haven't had a chance to use AJAX yet. I'm not sure if this is the right solution.I guess what I'm looking for is some sort of input on what is the most efficient way to do this and what is the best practice. Any input would be appreciated. Sorry for the long post.Thanks in advance.

[Shonumi]

I had a similar project like this that I did for myself a while ago. It had 550+ items in it, but loading all of these would have been a major pain in JavaScript. I didn't want to dabble with AJAX (because it was unnecessary for the case) so I stuck with JavaScript + DHTML. The trick was getting the data to the JavaScript. My solution was to load the data up as XML and parse it into arrays. This worked splendidly well. XML data, at best, shouldn't be measured in anything more than kilobytes, so downloading the file was fairly quick and didn't zap any of the browser's resources. Instead of having to query up or make a request to another page or database, the all of the information was loaded up in one shot. Having the data separate from the JavaScript code reduced a lot of headaches and was easier to maintain.Particularly, when your data is static and small enough, I find it better to do XML + JS + DHTML. The code for getting your data is a bit less tricky and more straightforward than in making your own AJAX scheme. My project required not just the use of text, but images as well. In the XML I just added a parameter to the tags that had the location of the image on the server, and the JavaScript took care of the rest. You can do the same with those ID numbers, as XML will allow you to have as many parameters as you need, and it's quite flexible. To me, AJAX just seems like too much for somethings that just need to get the data to the code. If you are dealing with gross amounts of data, then I would suggest AJAX, perhaps using a PHP page to request an SQL database. But if not, I wouldn't bother. Then again, if you really want to experiment with AJAX, this would be an opportune learning time.Note however, I still made use of the XMLHttpRequest, but that in and of itself isn't AJAX. In my case, there wasn't an asynchronous request to another page, and my page sent nothing back to the server, so it acted pretty much as a standard HTTP download. There wasn't a need to use AJAX in its fullest sense because that data didn't change, I just needed to download it.

[jeffman]

You're going to be transmitting the data one way or the other. So you might as well embed it as javascript objects on the initial download. Rearranging text content in the DOM is not a big hassle, especially if the page elements can stay the same, with only their content changing. You should get near-instantaneous results.With 600 items, what you want to avoid is destroying and re-creating page elements and their properties. That could cause a noticeable delay.I hope I'm making myself clear.If you have, say, a table with 600 rows and several columns, you should get good performance if you only change the text content of the table cells, and don't change any formatting or other properties. This is entirely possible since the number of rows and columns should stay constant. Even better if you use divs instead of table stuff.But you'll kill yourself if you use DOM techniques to delete all the table rows and then create new ones while you populate them with content. Depending on the system and browser, users very likely will see the data being rewritten to the screen, one row at a time, like venetian blinds unfolding slowly down the page.

[WebNerd]

Thank you both for your help. This gives me some good ideas. I think I know how I want to do it now.Deirdre's Dad: You are correct. I had not thought of this, but the number of items, and therefore the number of HTML objects, always stays the same. It's only the order in which they appear that changes. This will let me keep a lot of the existing code. I just need to change the displayed text and value when the list is resorted.One factor that I do not know is how often the users will resort the list. I usually take that into account when deciding whether to always include the data on the page or only download what I need and go back to the server for any additional data later. It would be a waste of resources to include all of the data if resorting is a rarity.

[jeffman]

You discuss including the data as if there's a choice. Trust me, if it's there, it's there. You can load it up in your tables, or you can embed it as javascript data, but either way it's there. You may not want to to duplicate it, maybe that's what you mean. But you can certainly "store" it in the table cells, and then move it temporarily into javascript arrays while you sort it and rearrange it. That's not a real duplication and won't affect performance.Or do you mean not bringing in all 600 items at once? That would depend on the way your data is structured. If chunking it would make sense to your user, then only requesting the relevant chunks when necessary might make sense.

[chibineku]

Another idea, since you're using javascript, is to use jquery. It has very powerful and efficient sorting methods built in. Worth checking out anyway. In fact I was reading just last night about table sorting in my jQuery book.

[WebNerd]

Deirdre's Dad:I'm not sure I understand what you're saying. Maybe I'm not explaining it thoroughly enough. I was thinking about how I'd make the data available to JavaScript in a format that is already sorted by name and also by ID. I looked into using JavaScript sort it dynamically, but that seemed a little complicated. There isn't a built-in method for sorting multi-dimensional arrays. There are only two ways to sort the data, and the data is the exact same for every user running the report. It seems better to prepare the data on the server and cache it for easy and quick access on the page.Right now, I'm approaching it as having two multi-dimensional JavaScript arrays -- one sorted by name and one sorted by ID. I suppose I could pull the data from the HTML table, but I'm not currently storing the name in the table in a pure format. What is in the table is the ID number (the value of the checkbox) and the name with the ID number in parenthesis (the displayed text of the checkbox). When I resort the data, I will still store the ID as the value, but I'll display the name as the ID number then the name. It also doesn't seem efficient if the user resorts the data more than once, which is totally possible.My comment about not pulling down unnecessary data was that I don't need the two sorted arrays if the user isn't going to resort the data. I could pulled down the sorted lists only when the user clicks the sort option. To be honest, I might be over-thinking this. Even as big as the two arrays are, they probably aren't large enough to impact performance in the slightest.I hope that makes sense. Please let me know if there's something I'm still missing.Thanks again for your help.

[WebNerd]

Another idea, since you're using javascript, is to use jquery. It has very powerful and efficient sorting methods built in. Worth checking out anyway. In fact I was reading just last night about table sorting in my jQuery book.

I've heard of JQuery, but I'm not very familiar with it. I will look into it. Thank you for your help.

[jeffman]

The Array.sort() function allows a "hook" to be passed as an argument, making it possible to sort multi-dimensional arrays. (All good languages have such a thing.) Example 2 here shows how hooks can be written. My versions come closer to your own application.

arr=[];arr[0] = ["Zebulon","123"];arr[1] = ["Abigail","987"];function by_name(a, b) {	if (a[0] > b[0]) {		return 1;	} else if (a[0] < b[0]) {		return -1;	} else {		return 0;	}}function by_id (a, b) {	return a[1] - b[1];}alert(arr.sort(by_name));alert(arr.sort(by_id));

I would normally write the by_name function more tersely, using compound ternary operators, but I don't know your programming level. FWIW, it looks like this:

function by_name(a, b) {	return a[0] > b[0] ? 1 : a[0] < b[0] ? -1 : 0;}

Now that you can do this, you can maybe simplify your process?

[WebNerd]

I found an example like that to sort a multi-dimensional array online. I'm not sure if I want to use that for this particular case, but it will definitely help me for some future work coming up. Thank you very much for your help.

[WebNerd]

After going through my old code, it appears that I misspoke. The list from which the user must select is actually different for each user based on access rights. Given that the data is more dynamic instead of being the same list for each user, it makes more sense to me to have the JavaScript to the resorting. I have the information I need to do this from the suggestions already provided. I'm going to play around with it a little to see which way I want to do it.Once again, thanks to everyone for your help.