Greg Donald wrote: > On Thu, Feb 11, 2010 at 2:19 PM, Marnen Laibow-Koser > <li...@ruby-forum.com> wrote: >>>�I'd rather let the client-side JS make this decision. > > The client side wouldn't yet know if my record was successfully saved > to the db or not.
Then that information could be in the JSON packet, because the server *would* know at the appropriate time. All it would need is one more field. It seems to me that in most cases, there's something conceptually wrong with sending *behavior* in the way you're describing, rather than *data*. I tend to think that if the client sends an Ajax request for (say) a record to the server, it should get back data for that record, which it can then decide how to render. This would also presumably make it easier to use the same JSON API for both internal Ajax and external Web-service consumers. It also means that JS files can be static, and thus cacheable by the browser. I like the simplicity of the RJS approach for certain trivial cases (and perhaps for cases where behavior, rather than data, is primarily what the client is requesting), but I'm finding difficulty in seeing how it can scale well or be maintainable. I'll probably play around with it at some point soon and see if I'm missing something that would change my mind. > > > -- > Greg Donald > destiney.com | gregdonald.com Best, -- Marnen Laibow-Koser http://www.marnen.org mar...@marnen.org -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-t...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-talk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
