I'm not really sure how it will help as you will massively bloat the pages with all of those pre loaded parts. Its why its ajax in the first place.
-- Sent from my Palm PreDave Roberts wrote: Thanks for the feedback. Point by point: How does this leave out security? If the person doesn't have permission to edit (or add), you would just not present the user that option. do_new methods. . . I'm new here, can you point out what this is? associated data updated: I'm assuming you mean how would related models be updated? The page would have to preload this data, for some applications this could be intensive, but for others it could be faster / nicer for the users concurrent locking: This is a valid point, but it's no different than two users accessing the edit page at once. When the first user updates, the second user is editing out of sync data. It's up to the author of the application on how to handle this conflict. Developer's specific procs. . . I'm not sure what this is. Converting all new and edit stubs to JS: I realize it's a pain since the software is already working this way. Again, it may not be the best choice in every situation, but I have applications where this would give my application a faster feel. I'm just wondering if such an undertaking were possible, and what it would entail. On Jun 15, 11:04 am, Hernan Astudillo wrote: > IMHO not good idea: > you leave out all security filters, do_new methods, associated data updates, > concurrent edit(update) locking, developers specific definitions/procs, plus > converting all new and edit stubs to JS > what if data changed between page load (list) and "new"(or "edit")? > > for better user experience i think it's good approach to mantain ajax calls > light as a ping :D > again, that's IMHO... > > On Mon, Jun 15, 2009 at 8:52 AM, Dave Roberts wrote: > > > > > Hello, > > > I was browsing and I noticed that pulling up the forms for Create New > > and Edit both send a request to the server. Would it be possible to > > make these calls not run to the server? It would be a better > > experience for the user. What would the design look like? It is > > possible? What trade-offs would it have? How could it be implemented? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "ActiveScaffold : Ruby on Rails plugin" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/activescaffold?hl=en -~----------~----~----~----~------~----~------~--~---
