I am currently have a ''products'' table that has a ":has_many" relationship with a ''photos'' table. I am uploading photos to accompany products. Right now, I upload the photo, save the metadata to the ''photos'' table and the image to the filesystem. Then, I direct a url from within the products display pages to point to a thumbnail generator. For example, /products, would display all the products with the product''s associated images. The images would be formed by <img src="/photos/thumbnailer/? height=200&width=200 ?>. The ''/thumbnailer'' action then generates, saves (based on sizes), and displays the thumbnail of the uploaded file. If another request comes in for the same page, the saved thumbnails are displayed and the ''/thumbnailer'' action does not generate any new images. Thus, there is heavy overhead only on the first request. I like this because if I ever wish to change the layout of the site, all I have to do is change the url to meet the new parameters. However, I have seen that most of the plugins that help with file uploads tend to generate thumbnails at the time of file uploads. For example, maybe a ''small'', ''medium'', and ''large'' thumbnail are generated and served up throughout the site. However, this seems like more of a hassle to update if the design requirements change. Since I am a new programmer, I am sure there are good reasons why others do it differently (like many of the plugins). Any thoughts? What drawbacks am I missing with my method? Thanks Andrew
On Fri, Aug 21, 2009 at 6:20 AM, Andrew Pace<andrewppace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > I am currently have a ''products'' table that has a ":has_many" > relationship with a ''photos'' table. > > I am uploading photos to accompany products. Right now, I upload the > photo, save the metadata to the ''photos'' table and the image to the > filesystem. Then, I direct a url from within the products display > pages to point to a thumbnail generator. For example, /products, > would display all the products with the product''s associated images. > The images would be formed by <img src="/photos/thumbnailer/? > height=200&width=200 ?>. The ''/thumbnailer'' action then generates, > saves (based on sizes), and displays the thumbnail of the uploaded > file. If another request comes in for the same page, the saved > thumbnails are displayed and the ''/thumbnailer'' action does not > generate any new images. Thus, there is heavy overhead only on the > first request. I like this because if I ever wish to change the > layout of the site, all I have to do is change the url to meet the new > parameters. > > However, I have seen that most of the plugins that help with file > uploads tend to generate thumbnails at the time of file uploads. For > example, maybe a ''small'', ''medium'', and ''large'' thumbnail are > generated and served up throughout the site. However, this seems like > more of a hassle to update if the design requirements change. > > Since I am a new programmer, I am sure there are good reasons why > others do it differently (like many of the plugins). Any thoughts? > What drawbacks am I missing with my method? > > Thanks > > Andrew >Doing it your way would mean that you have to keep track of whether a thumbnail has been generated or not (extra complexity) You would also have to run your image request through the Rails stack instead of just serving the image from the file system. By processing the images at upload, you now have images that can be quickly served from the file system without going through Rails for checking first. If you want to change the layout of your site, you can run a batch process that re-processes all the images to the new dimensions. A number of the plugins allow for reprocessing Photo.find_in_batches.each do |batch| batch.each do |photo| photo.reprocess! #<- psuedo method end end Andrew Timberlake http://ramblingsonrails.com http://MyMvelope.com - The SIMPLE way to manage your savings
Andrew Pace wrote: However, this seems like> more of a hassle to update if the design requirements change. >Look at it this way: Suppose you have the "next big thing" and everyone is flocking to your site to see and read about it. Do you want your response cycle dependent on a hunk of code checking whether thumbnails of a set of product images exist for every request that hits a URL (especially when your intent is to have those thumbnails available for serving)? For 10 users? For 10,000 users? For X users? Or do you want your application to generate those thumbnails once, when the images are uploaded? Don''t defer work that must be done, that''s not simplicity. Get it out of the way as soon as possible. Anecdote: At work a year or so ago, I was asked to improve performance for a web process. In a nutshell, I a) stopped ''dynamically retrieving'' certain data (that wasn''t truly dynamic) and formatting the results for the web on the fly, but formatted and stored it at schedule creation. In one test case, we went from 7000 queries to under 300, and the response time went from 28 seconds to 3. Main lesson: make the real work happen outside your request-response cycle -- Posted via http://www.ruby-forum.com/.