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

[Cliff Moon <cliff@chariotsolutions.com>]

I might be misunderstanding your explanation of the user experience, but
it sounds to me like you're trying to persist changes for each
interaction with a page using xhr calls.  So my comments are only
relevant if that is your intention.

Is it a requirement that user interaction be persisted at each step?  If
not, you may want to think about just manipulating your data structures
on the client side and tossing everything to the server once the user
clicks save/commit/whatever.  That will drastically reduce the number of
requests per user, which is a big win.  And from a usability perspective
it will make more sense to your users, who are probably very used to the
request-response cycle of the web.

Is there a multiuser aspect to this that I'm missing?  Are multiple
users manipulating the same datasets concurrently?  You mentioned that
the client and the server might get out of sync, which is why I ask. 
Maybe getting a higher level overview of the architecture might help.

Brian Donahue wrote:
> Hi,
>
> 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:
> http://lists.phillyonrails.org/mailman/listinfo/talk
>   

_______________________________________________
To unsubscribe or change your settings, visit:
http://lists.phillyonrails.org/mailman/listinfo/talk