Though there’s been a few attempts at creating high-level, pluggable components in Rails, nothing has really seemed to catch on. There’s Rails engines and some full-blown CMS packages, but there’s still a tendency to built things from the ground up. Why is this?
I’ll list a few low-level tools that you can integrate into any project, that don’t mess with Rails internals and are dead-easy to set up and use.
-
acts_as_tree or acts_as_nested_set
Built into Rails, these will give you a tree model for any model objects. Sprinkle on LiveTree for a Javascript-based UI.
-
acts_as_versioned
Store previous copies of Pages, Assets or any danged model that you please.
-
acts_as_versioned_association
Building on top of acts_as_versioned, this provides versioning support for your associations, so if you had a
Pagethat had associatedImageAssetsyou could retrieve an exact copy of your page along with the associated image assets at that point in time. -
Polymorphic associations
Built into Rails 1.1, polymorphic associations allow you to associate a model with any other type of model through a polymorphic join association. This means you could tack a Comment onto any of your model objects, like in the following example:
class Comment < ActiveRecord::Base belongs_to :commentable, :polymorphic => true endAdding comment support to a model is simply a matter of inserting a
has_manyone-liner:class Post < ActiveRecord::Base has_many :comments, :as => :commentable end -
acts_as_attachment
Provides both file and DB-based upload storage, as well has ImageMagick support for auto-resizing of images. If this isn’t flexible enough there’s the more image-manipulation-based ImageMagick for Rails plugin.
What other building blocks have you used when adding typically CMS-like features to your Rails application?
June 13th, 2006 at 10:22 am
Interesting, I was just about to go from my homepage (sitepoint)to Google to check for a RoR CMS… LOL
Thanks for the information Tim!
June 13th, 2006 at 8:57 pm
I’ve been using “scaffolding extensions”… fairly easy to set up, configurable, but maybe broken now (I believe) because of errors on record deletion (it tires to show the record after it deletes it) and wrong (certainly not useful!) redirects on create/update.
June 13th, 2006 at 10:21 pm
Instead of the ImageMagick plugin, how about the File_Column plugin? Much more flexible, and you can use it with acts_as_versioned to get the versioned assets you speak of.
June 13th, 2006 at 11:38 pm
Thanks Mislav, hadn’t noticed the scaffolding extensions plugin.
hotgazpacho: Ha, I’ve actually used file_column but have never touched the ImageMagick plugin I mentioned. Thanks for pulling me up on that. I much prefer the file_column approach of resizing on upload, rather than serving up assets from Rails (cached or not). I’ve had problems in the past with that approach, but it could have just been an early version of Rails on an unstable set up.
June 14th, 2006 at 5:13 am
Here’s another little tidbit from my application_helper.rb:
# Generate an image tag for a magick_file column # expects method and size to be symbols def image_tag_for_magick_column(object, method, size) img = Magick::Image.read(object.send(method.to_s, size.to_s)).first image_tag(url_for_image_column(object, method, size), :size => "#{img.columns}x#{img.rows}" ) endProbably want to wrap this in a block, though, so you avoid reading the image every time just to get the pixel dimensions, unless someone knows of a better way…
June 14th, 2006 at 5:13 am
That would be a “cache do” block…
June 23rd, 2006 at 12:08 am
Where is the credit for the code highliter?
June 23rd, 2006 at 7:53 am
Not sure about the credit for the code highlighter… I’ll find out more and report back.
June 23rd, 2006 at 11:49 am
The code highlighting plug-in we use may be found here:
http://www.dreamprojections.com/syntaxhighlighter/
As far as we are aware, there is no requirement for us to credit this library each time we use it.