Rails on the Run

Rails experiments by Matt Aimonetti

Browsing Posts tagged attachment_fu

I recently bugged Rick Olson so much about attachment_fu that he gave me SVN access to fix few bugs.

Rick being really busy with ActiveReload he didn’t spend too much time maintaining attachment_fu.

On my side of things, I’ve been using attachment_fu on a lot of projects and I’ve been fixing bugs and adding new features.

My first contribution to attachment_fu is a fix for the ImageScience processor.

Attachment_fu is very flexible and let you use your favorite image processor:

Like many rubyists, I like ImageScience for its simplicity and efficiency. However, attachment_fu had few problems when being used with ImageScience.

  • File sizes for thumbnails were not saved correctly in the database. Fixed
  • Thumbnails based on a gif files were not processed properly. So, this was the big problem. FreeImage has issues dealing with resizing gif files because of the gif palette limitation (256 colors). to avoid this problem thumbnails of gif files are converted to png. However the thumbnail content type info in the database was not saved properly. That’s now fixed.
  • Because of the gif bug reported above, any thumbnail link was broken since it was trying to link to the thumbnail version with a gif extension instead of a png one. Fixed

I also fixed a small bug related to S3 storage and the fact that a_fu had issues loading the config file. (Fixed)

I’ll also try be able to add some of the S3 features I’ve been working on. As well as maybe enhancing the validation process.

In the mean time, you might want to read this blog post about better validation with attachment_fu.

If you are heavily using attachment_fu or starting using it and think that a google group would be great idea, please let me know in the comment and I’ll try to convince Technoweenie that we need to set that up :)

Ooohh I almost forgot, if you fixed some bugs you found while using afu, please contact me so we can get afu bug free.

Here is another type for attachment_fu users.

This evening I wanted to try Railroad to generate one of my app diagram. I alreay wrote my own script generating a .dot file that I usually import in omnigraffle before exporting a pretty version for my clients. The thing is, my script is quite simple and only covers models while railroad also deals with controllers.

Wanting to check on railroad, after installing the gem I typed

 railroad -o models.dot -M

and here is the ‘pretty’ error message I got.

railroad error msg

No worries, Technoweenie didn’t mess up, it’s just that I use s3 for storage and his great plugin checks on the environment to load the proper credentials. Since railroad doesn’t care about the environment, RAILS_ENV isn’t set and my model diagram isn’t generated.

To fix this issue, simply type:

$ railroad -o models.dot -M RAILS_ENV='development'

I recently had to deal with an interesting challenge. I had to write a simple interface between a rails app and a Flash application. Nothing hard and if you browse the archives, you’ll find examples and tutorials on how to create a REST interface to communicate between Rails and Flash.

The thing was that this time I had to interface with a model using attachmentfu. I’m a great fan of afu and it’s definitely the best way of dealing with uploads.

My model looked more or less like that:

class Photo < ActiveRecord::Base

belongs_to :user

    :content_type => :image,
    :storage => :file_system,
    :max_size => 10.megabytes,
    :resize_to => '640x480>',
    :thumbnails => { :thumb => '100x100>',
                              :preview => '300x200>',
  # read more about validates_existence_of http://blog.hasmanythrough.com/2007/7/14/validate-your-existence
  validates_existence_of :user

My show action in my photo controller could have looked a bit like that:

respond_to do |format|
  format.html # show.html.erb
  format.xml  { render :x ml => @photo }

That’s great, the problem is that we are displaying a lot of information that our Flash client doesn’t need to see, actually we are exposing a lot of information nobody should ever see and we are not displaying what we should. On top of being a waste of bandwidth and giving too much work to the client, we are not actually providing the user with the details of the thumbnail.

The first thing to do would be not to display some of the object attributes, the to_xml method lets you do that.

Note that in Edge, Rails will automatically try to convert your object using toxml, you don’t even need to mention it. However in our case, we want to use some _advanced features offered by to_xml, and here is how our code should look like:

format.xml do
  render :x ml => @photo.to_xml( :except => [ :id, :filename, :updated_at, :user_id, :height, :width], :skip_types => true )

What I just did is very simple, we rendered our object as an xml object but we didn’t convert few attributes, :id, :filename, :updatedat, :userid, :height, :width. By default Rails also adds the object type, we don’t really need that right now, so let’s skip them.

(The reason why I don’t want to convert the filename is that I want to provide our Flash client with the photo thumbnail instead of the original picture.)

As far as I know, to_xml doesn’t let you create new attributes. (if I have some time, I’ll submit a patch to get that added).

What we are trying to do is to display the avatar of a user. We found the photo record using @user.photo but that’s the original photo and we want to provide Flash with the avatar info, not the original.

What we need to do is to simply add a new attribute called avatar:

format.xml do
  @photo[:avatar] = @photo.public_filename(:thumb)
  render :x ml => @photo.to_xml( :except => [ :id, :filename, :updated_at, :user_id, :height, :width], :skip_types => true )

Simple enough, but it took me a little while to figure it out ;)

Voila, we now have a clean, trimmed and safe XML returned object that you can be consumed by our Flash client. Ohh, and we added a new attribute that the original object didn’t have :)