views:

258

answers:

4

I'm building a Web Page that allows the user to pick a color and size. Once they have these selected I need to perform a lookup to see if inventory exists or not and update some UI elements based on this.

I was thinking that putting all the single product data into multidimensional JavaScript array (there is only 10-50 records for any page instance) and writing some client side routines around that, would be the way to go for two reasons. One because it keeps the UI fast and two it minimizes callbacks to the server. What i'm worried about with this solution is code smell.

As an alternative i'm thinking about using a more AJAX purist approach of using HTTP handlers and JSON, or perhaps a hybrid with a bit of both. My question is what are your thoughts as to the best solution to this problem using the ASP.Net 2.0 stack?

[Edit]

I also should mention that this page will be running in a SharePoint environment.

A: 

I would go with your second option by far. As long as the AJAX call isn't performing a long running process for this case, it should be pretty fast.

The application I work on does lots with AJAX and HttpHandler, and our calls execute fast. Just ensure you are minimizing the size of your JSON returned in the response.

steve_c
A: 

Go with your second option. If there are that few items involved, the AJAX call should perform fairly well. You'll keep your code off the client side, hopefully prevent any browser based issues that the client side scripting might have caused, and have a cleaner application.

EDIT

Also consider that client side script can be modified by the user. If there's no other validation occuring to the user's selection, this could allow them to configure a product that is out of stock.

Justin Niessner
Just curious: it seems like an AJAX call would be more code (and code that is trickier across browsers at that) than a simple served once.
Joel Coehoorn
That is what i'm really torn between as well. Just because it's a newer way of doing things doesn't necessarily mean that it's better.
James
There should _always_ be server side validation.
AKX
+4  A: 

Assuming the data is static, I would vote option #1. Storing and retrieving data elements in a JavaScript array is relatively foolproof and entirely within your control. Calling back to the server introduces a lot of possible failure points. Besides, I think keeping the data in-memory within the page will require less code overall and be more readable to anyone with a more than rudimentary understanding of JavaScript.

John M Gant
+1 You make a good point.
James
Agreed, unless the client side script is your only validation before the user makes their selection. With client side script, the user could modify the array allowing him to select something that is really out of stock.
Justin Niessner
I agree with this answer. One additional thing to add: users can/will leave their browsers open for extended periods of time. Going with option one means that you need some way of dealing with actions that are based on bad/old data.
AaronSieb
@AaronSieb - when writing web-apps, you must always assume the data is old/rotten/hazardous, not only in this case
Berry Tsakala
+2  A: 

i'm against Ajax for such tasks, and vote (and implemented) the first option.

As far as I understand, you won't create Code smells if the JS part is being written by your server-side.

From a user point-of-view, Ajax is an experience-killer for wireless browsing, since any little glitch or mis-service will fail or simply lengthen the interaction by factors of 20(!).

I've implemented even more records than yours in my site, and the users love it. Since some of my users use internet-caffee, or dubious hotel wifi, it wouldn't work otherwise.

Besides, Ajax makes your server-vs-client interaction code much more complex, IMO, which is the trickiest part in web programming.

Berry Tsakala
+1 I was leaning this way to begin with, but it's nice to have some re-assurance from the SO community.
James