Thanks for your reply. Yes, they are conceptually quite similar. I appreciate the example you shared.
I've been thinking about this some more. Here are thoughts of mine: When dealing with data and communication between machines, it has been my experience that keeping business state (domain data) on the server is best. Where possible, one should code the solution so that data on the client (browser or app) is merely a reflection of the business domain data which is on the server. This can involve getting the whole set of objects from the server instead of just adding/deleting the items in the GUI (browser). This helps with many issues such as someone losing their internet connection and then getting it back. It's also easier to maintain / debug. When the user does the unexpected such as open multiple windows, things work better as well (more robust). This approach has saved a former software developer team of mine before. Example of NOT keeping state on the server and keeping state in the page would be the following: 1) user client contains 4 items; A B C D 2) user successfully removes item B. List shows A C D. 3) user loses internet connection 4) user tries to remove C and D, fails due to lost connection; however, user interface shows C and D as gone. 5) user closes window, opens a new window, sees C and D are there. (other scenarios with multiple windows / tabs apply as well) Granted: someone can use the failure/success responses from a $.ajax call to code more intelligence into the client. However, if you maintain state in both the client and the server, you are signing up for additional synchronization work between the client and server which may not be necessary when dealing with a small set of items. Having said all that, I am going to read current best practices some more on this. We'll see if I still feel this way after reading more on the topic as time goes on. Thanks again for sharing your thoughts and application. :) On Aug 15, 11:15 am, Stephan Beal <[email protected]> wrote: > On Aug 15, 5:42 pm, finneycanhelp <[email protected]> wrote: > > > Some options are available here to meet these requirements. > > > - For showing the list and hiding Add Names when list size = Count, > > should one: > > Store the Sample List into something globally accessible in the page > > OR request the list each time something about the list is needed > > (size, content) > > OR .... > > What is the simplest and cleanest approach? > > > BTW, the list is requested each time an item is added or removed right > > now. It seems easier to debug that way. > > i think that conceptually you're trying to do something like i > recently did for an app. It wasn't a list of names, but a list of > cybertanks for a wargame i like to play. In that app (http:// > wanderinghorse.net/gaming/ogre/byoo/ajax/) i did the following (that's > not to imply that this is "simplest" or "cleanest"): > > At startup, i load all of the app data (a bit over 100kb) into the > client. It is transfered as JSON and then transformed to higher-level > app objects. However, i keep the original JSON db around, partly so > that i can figure out if a user has modified an object (i.e. if it > needs saving) and partly to implement a "revert changes" option > without having to request the data again. When the user uses "save", > we convert the high-level app object to JSON, update the local > internal copy of the JSON data, and send it off to the server. > > For really large data sets i wouldn't keep the whole thing in memory, > but this particular app is intended to be a "rich client", and not > just page dressing, so i wasn't too concerned about memory usage. > However, i am considering re-modeling it to request data only as > needed. i think the determining factory here is how much traffic (and > request count) i save using one approach or the other. i haven't > analyzed that yet, so i can't yet make an informed decision. > > Maybe poking around the above app with firebug would prove > informative. Feel free to use the editing features (they're open to > all w/o any sort of login) - you can then watch the json transactions > using firebug.
