Brian Donahue on 5 Sep 2007 17:22:02 -0000

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

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

Thanks, Casey.   That sounds very interesting, especially to someone that saw Ghostbusters at least 5 times in the theater as an impressionable 11 yr old (There is no data, only XUL)...

I'd be interested to hear more about the design sometime, how you structure the _javascript_, etc.  My particular concern would be the updating process.  The app I'm working on basically takes a big list of items, and allows you to categorize with drag/drop.  The tricky bit is that some of the categorizations are date based, so as days pass, they change (from "tomorrow", to "today" for example).  So to get the counts for (at least some of) the categories, I have to query the full list for those that match the criteria.  I'd either have to do that on the server, and have each UI representation of a count do a separate call to get its data, or I'd have to return the full list of items (which could conceivably be in the hundreds, *maybe* over 1000, although < 10 simple data fields per item) and run the queries/counts on the client to update. 

On 9/5/07, Cassius Rosenthal <> wrote:
I've written several XUL apps that work that way: client-side code is
bootstrapped on the first request to the web server, in an index file or
whatnot.  All subsequent http requests are xml or json.

Often, development for an app like this goes something like:
*) Make all or most of the application 'pages' in standard XUL/XML/HTML.
*) Move the navigation controllers to client-side, and simulate posts
with 'save' buttons, etc.
*) Finally, move all other controllers to client-side, and use event
observers to automate interactions with the server.

The end result is a mostly client-side MVC app where the M is on the
server, and the VC is on the client.  The Rails controller only
coordinates sending the data to the client and handling sessions, and
the Rails view only bootstraps the client-side code.  The app will then
feel like a regular desktop app, with responsiveness dependent on
network lag.

The synchronization problem has for the most part been solved.  What
happens when you open the same document twice?  Expected behavior is
that your OS either brings the open document to the forefront, or
prompts you to refresh the view if you return to the original when the
copy has been changed.  Using an encapsulated application in XUL, you
can implement the former solution in the DOM.  Otherwise, you can use
onFocus to compare updated_at values, and prompt for the refresh.

Good luck!


Brian Donahue wrote:
> It is becoming more clear to me that I was trying to push too much
> business/view logic into the client code, thinking of Ajax/_javascript_
> as a way of interacting with raw model objects, rather than as a way
> to dynamically update the web UI.  I think for the browser, I should
> stick to passing back HTML/JS that updates the view (like everyone
> else, duh!), not raw data that is then handled by client code.
> Obviously, I can return raw JSON or XML for other types of requests
> should I choose to go that route later, but thinking about that first
> was causing me to forget how you build a web app :)
> You'll still have the possibility of getting out of sync with multiple
> tabs/windows, but at least in that case, a single action/request
> should be able to sync you back up.
> On 9/4/07, *Aaron Blohowiak* <
> < >> wrote:
> Sounds like you don't want to be turning a stateless platform (HTTP)
> into a stateful one.  No matter how you concieve of it you're going to
> have to a) maintain synchrony and b) run into headaches (see (a) for
> more information.)
> You can monitor the fields and data to ensure that all changes on the
> client side have been submitted before the browser changes pages, a la
> gmail, but even this will not ensure that you will stay in synch.
> For instance, how do you plan on handling people having multiple tabs
> open? Comet push?
> Real sticky wicket.
> ------------------------------------------------------------------------
> _______________________________________________
> To unsubscribe or change your settings, visit:

To unsubscribe or change your settings, visit:

To unsubscribe or change your settings, visit: