I think you could push the limits of what the browser and the user's CPU is capable of in a responsive manner. It's far better to load, say, the first page of "hair" and then, if they click on the next page, to fetch the next page and merge the data with the first group (or have an array of hair page data or something). Using up memory this way isn't too big of a deal given that most computers these days have at least a few hundred MB of RAM (and most over a GB). But processing thousands of records on startup will produce a noticeable lag. As for assets.images, here you must be more careful. You should "retire" content when it moves to far away from the view. For instance, say you load the first page of hair and display it. You might also load the 2nd page so that moving to page 2 is super fast. But if the user navigates to page 9, you don't want to keep page 1 and 2 around. You need to expire things smartly to keep memory usage down (esp if there are thousands of items).
-aaron On Thu, Jul 23, 2009 at 3:00 PM, Ryan Florence <[email protected]> wrote: > > So I've got a site that's got something along the lines of the Mii creation > tool on the Wii. There's a stage where the user adds images by category > (hat, hair, glasses, etc.) and moves them around to wherever they like. > > At the moment I'm bringing in each category via Request.HTML and then just > updating the div that displays all the different items (like hair styles). > Each element (or hair style) had it's database info in an attribute of the > element. > > We had this discussion a few days ago, and it's got me thinking. So I was > switching the request to Request.JSON and then drawing the elements out via > javascript (instead of echoing it out in PHP via Request.HTML). Then I had > all my data in an object and didn't have to worry about using an attribute > on the element. > > Then I thought, "Why not just load the entire database of items into an > object, then just deal with it all client side?" > > Our plan is to eventually have thousands and thousands of items, that's why > I went with request so that I didn't have to load them all in unless the > user selected the category. > > I'm entirely tempted to use Asset.Images in accordance with a big fat > object that contains all my database instead. Is there ever a concern of how > big the object will be? It's certainly going to be less space the images it > loads. > > -Ryan >
