[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
Re: [PhillyOnRails] Question re: Ajax and REST design, and maybe even Rails
|
Yeah, I was assuming (without Firebugging, or otherwise snooping) that gmail may work that way. I was struggling with how to avoid duplication - in logic, as well as data persistence between the client and server. Not that it can't be done - there are probably a lot of good patterns in the "smart client" desktop app world, with which I have minimal experience.
On 9/4/07, Aaron Blohowiak <aaron.blohowiak@gmail.com> 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....
This is an interesting way of doing it, and there are a few attempts. For instance, IIRC, this is basicly how openlaszlo (spelling) works.. the ui is essentially a gui toolkit that gets loaded and then the data is passed back and forth with the server. On the one hand, this sucks for all of the obvious reasons, but on the other it rocks cause you keep the data and the display seperate until it gets displayed. Anyone with more experience want to chime in here?
IIRC, the google apps work similarly to how you proposed (at least gmail does.) But they are using Java to write out the _javascript_ that handles the JSON.
As I get more experience, for nontrivial UIs, this method seems more appealing.
-Aaron
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 <aaron.blohowiak@gmail.com> 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:
http://lists.phillyonrails.org/mailman/listinfo/talk
_______________________________________________ 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
|
|