# Preloading results in Ajax App **URL:** \ **Category:** Rails\ **Created:** [June 27, 2006, 2:24pm UTC](https://www.ruby-forum.com/t/preloading-results-in-ajax-app/96226 "2006-06-27T14:24:00Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![sudara](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/9d8465/32.png) [@sudara](https://www.ruby-forum.com/u/sudara)\ **Post date:** [June 27, 2006, 2:24pm UTC](https://www.ruby-forum.com/t/preloading-results-in-ajax-app/96226/1 "2006-06-27T14:24:00Z")
Hello Rails lovers! I have a few general discussions that I have yet to find terribly active. Perhaps all of the people busy on this front are…uh…busy on this front. So! Ajax-only apps. No degration. Yes! Forget about degradation for a moment. Not willing to? Ok, well…this question is for those who are willing… Imagine developing an app that is one page - all actions render partials on this page, probably with rjs. Already done it? Great, these questions are for you then: 1. Browser pre-loading. I am interested in NOT having the user sit around while my software loads and renders 10 results at a time, just like a ‘normal’ webpage. Not sexy. Updating and redrawing a part of the page is only the tip of the iceberg… I feel that it is time to be able to make sorting through larger amounts of data much more sexier, as a standard… Here is my answer to this question, perhaps you have comments, or can enlighten me with other answers. — A Client-side pre-loading framework…Aka, on the page load we load 100 results into the browser, hide 90 of them in “display:none” divs, then when we click on another page, no server calls are made, we just use Element.show and hide to jump through the results. To me, loading extraneous data on 1 sever call, saving 4 or 5 extra calls is much more ‘user-time-efficient’ than expecting the user to watch a rolly ball spin over and over again to load a couple kb… It seems to me that the only way Ajax is really going to make the web sexy is if 3 out of 4 requests coming from a client are handled locally, and the user wait time is reduced. 1. Periodic “background” calls from the client update the server with client side changes…This method seems a bit more complex, would involve loading the page data into javascript objects, having the page actions modify those javascript objects, and then calling the server on a regular basis to sync…Writing messages in Gmail seems to give the illusion of working in this way, where it saves periodic drafts of messages without worry or concern on the user’s behalf. If the current copy of the message is not saved, and you try and navigate away, you get a popup asking what you want to do with the draft. Rails seems like the ideal candidate for this kind of advancement in app development. In the name of DRY, it would be useful to find the most efficient paths, implement them once, and then walk away. Already it is amazing to make a call like “sortable\_element…” or “page.replace\_html” - very sexy…Dragging and dropping is amazing! But on every drag, every drop - a server call? There must be a better way, and I am very interested in finding/developing it… As far as I know, no larger framework or plugin currently exists to really take applications to the ‘next level’…for example: page.cache\_and\_paginate ‘div\_container’, ‘hidden\_div\_series’, :partial =\> ‘single\_result’ or \<%=droppable\_element ‘add\_to\_favorites’, :sync =\> true %\> page.sync ‘add\_to\_favorites’, page.sync ‘my\_sortable’ page.sync :all Ideas? love sudara ---
**Author:** ![sudara](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/9d8465/32.png) [@sudara](https://www.ruby-forum.com/u/sudara)\ **Post date:** [June 27, 2006, 2:46pm UTC](https://www.ruby-forum.com/t/preloading-results-in-ajax-app/96226/2 "2006-06-27T14:46:22Z")
I’ve thought of this problem as well. But hidden divs wouldn’t cover it for everything. I think the way to do this sort of thing is with javascript arrays. Hidden divs would work for a standard table, but not really so well for an autocompleting search box, for example. I think a great way of doing this would be to have ajax begin loading data into an array after the main page has loaded, and carry on in the background 'til it’s all done. When some data is needed, the javascript would then check if the data is already in the array. If it is, it displays it, and if not, it loads it, displays it, then carries on loading all the other data. Of course, for any of this to be practical, we’d need someone to make a ruby class to DRY it all up in rails, so all this can be done easily. I don’t feel up to the task… it’s a pretty big ask of even the most experienced rubyists. But that’s my idea of how it would work ideally. Just my opinion. -Nathan ---
**Author:** ![sudara](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/9d8465/32.png) [@sudara](https://www.ruby-forum.com/u/sudara)\ **Post date:** [June 27, 2006, 6:07pm UTC](https://www.ruby-forum.com/t/preloading-results-in-ajax-app/96226/3 "2006-06-27T18:07:43Z")
I would like to hear from some more of the experienced rail-riders out there about how they organize their ajax-heavy apps. My initial impressions are these: ++++ MVC breaks down when developing a more advanced ajaxed app. Rails is so sexy for standard apps, but the ajax integration feels adhoc…Easy to throw some spice into a ‘normal’ app…not so easy to build from ground up a complex application…RJS officially appeared in 1.1, so we are at the beginning of true integration. Currently, I feel like I am developing MVC+javascript-mish-mash, not MVC. Please do not read me wrong: I feel like a superhero writing code like ‘page.replace\_html’ or ‘page.callMyOwnFunction’ It is wonderful to code ruby/rails lines and receive complex javascript functionality, but I am curious and wanting to be a part of future integration, or at least gather the current ideas and methodologies… If our User-At-Large is going to take web drag and drop/sub-page updating seriously, there needs to be more major work to optimize data loading, standardize user notification, etc. It is time that apps like fluxiom are not unusual and targeting for the ‘high-tech’ web community. But right now you cannot build a fluxiom in Rails. You can build fluxiom in Rails if (and only if) you kick-ass at javascript, and either expect the user to be ‘cutting-edge’ or write a lot of custom code to satisfy user expectation. ++++ Because of the MVC breakdown, there is also a breakdown of the standard sexy rails workflow of model-controller-action-view-partial… I could not find a decent workflow path in Rails to take care of all of my rjs calls. I rewrote and reorganized the code many times…First I started with a the standard rails structure, then realized that it was best for me to code all of my actions in one main controller, the ‘browse’ controller, as all of the events were ocurring on one page. +++++ The flash[] system is great. For my all-ajax app, I built my own, ignoring what was present. I’m sure not the best idea, but there seems to be a need for displaying user-information - otherwise Ajax apps will continue to be built with a ton of WET code. Really, this is all just an excuse for taking a break from coding in the best framework I have ever used. If you are in doubt while reading any of this, please realize my interests are to ‘give back’ via sharing my experiences, and putting a call out for some ‘best practices’ love sudara unknown wrote: > I’ve thought of this problem as well. But hidden divs wouldn’t cover > it for everything. I think the way to do this sort of thing is with > javascript arrays. Hidden divs would work for a standard table, but > not really so well for an autocompleting search box, for example. > > I think a great way of doing this would be to have ajax begin loading > data into an array after the main page has loaded, and carry on in the > background 'til it’s all done. When some data is needed, the > javascript would then check if the data is already in the array. If it > is, it displays it, and if not, it loads it, displays it, then carries > on loading all the other data. > > Of course, for any of this to be practical, we’d need someone to make > a ruby class to DRY it all up in rails, so all this can be done > easily. I don’t feel up to the task… it’s a pretty big ask of even > the most experienced rubyists. But that’s my idea of how it would work > ideally. Just my opinion. > > -Nathan