Brian Donahue on 4 Sep 2007 17:53:57 -0000

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

[PhillyOnRails] Question re: Ajax and REST design, and maybe even Rails


I'm currently wrestling with the best structure for a seemingly simple app I'm working on, and am hoping someone on this list can offer some sage advice.  I should let you know first off that I am currently NOT using Rails for this, as I'm still most competent with .NET, am working with another .NET guy, and we're trying out the Monorail project for .NET.  If you haven't deleted this email yet, let me add that I'm not adamantly opposed to giving it a shot in Rails, I currently am more concerned about getting the browser/server interaction "right." 

Basically, the UI has a list of items as the central content, and a bunch of "drop zones" on the right, to which you can drag and drop any of the items in the list.  Clicking on the "drop zone" then displays the list of items that have been "dropped" there (and you can drop them somewhere else if you like).  The drop zones can be thought of as lists with certain criteria declared.  Dropping an item basically just sets the properties on that item to match the list criteria, and the counts/lists for each zone are retrieved by querying on those criteria.  It *is* possible for an item to be in two different lists (or zones) if they have some overlapping criteria (for example, if something has been dropped in the "End of week" list, on Friday it will also be in the "Today" list)

So here are some rough specs (I would say user stories, but I don't feel like typing the whole "as a ____ I want to ___ yadda yadda")

1) Create an item in the current list - the item would show up at the bottom of the list, and be set with the correct attributes for that list.  As mentioned above, if the item is eligible for any other lists/zones their counts would be updated appropriately on the right.
2) drag an item from the main list to another list/zone.  Attributes will be set accordingly, and the item count for that zone will be incremented, as well as any other zones that the item is now eligible for.  If the item is no longer eligible for the original list, it will be removed from the display.

That covers the two main scenarios.  It *feels* to me like I have two choices.
1) Maintain a client-side list of items that is fetched on the first page load.  Each time an item is created, updated, or deleted, I can make the appropriate REST call, and if successful, update the client-side list accordingly, re-run all the counts for drop zones, and re-display the current list (or try to smartly add/remove the item to the current list).
2) Each time an item is created, updated, or deleted, I can make the appropriate REST call, re-fetch the entire item list, and re-run all the counts for drop zones, and re-display the current list.

#1 seems to have the disadvantage of being able to easily get out of sync with server-side data, especially if multiple browser windows are open, etc.  #2, seems to be overkill to re-fetch all that data each time (although admittedly it probably wouldn't be a HUGE request). 

I am wondering if anyone has any best practices/patterns they could point me to, or briefly explain, about how to handle this.  I'm trying to minimize requests/DB hits by not getting each zone's count dynamically after every update, or by re-loading the list each time and updating the count via _javascript_, but I also don't really like the idea of the client-side getting out of sync with the server-side data. 

Thoughts, anyone?  I am open to hearing how Rails would help if it is specific to my problem - beyond that, I dont' really need to be sold on Rails.  I think Rails is awesome (even went to RailsConf 1.0), it's just not easy to jump into as a consultant, when I have been doing .NET for so long, and my clients all support it, etc.  This is an internal project though, so I may end up going that way, but I also would like to get some Monorail experience for the clients that I have to do .NET with, at least I could escape the horror of ASP Webforms.
To unsubscribe or change your settings, visit: