From: brabuhr@...
Date: 2008-08-10T00:20:27+09:00
Subject: Re: perl and the culture of libraries

On Tue, Aug 5, 2008 at 10:48 PM, David Masover <ninja@slaphack.com> wrote:
> And ActiveRecord -- why, exactly, is validation included? Why not make it a
> mixin? That way, with duck typing, I could pull at least some of the default
> Rails validations into another ORM. (validates_uniqueness_of might even work,
> if the #find methods are similar.)

There is an experimental project to pull parts of ActiveRecord (e.g.
validations)
into external mixins that can be shared with other model layers:

http://dev.rubyonrails.org/svn/rails/tags/rel_2-0-1/activemodel/README

"Also note that because this module MUST be able to stand alone (for
use in presenters etc), it does not COMPLETELY supplant
ActiveRecord::Validations. AR-specific stuff like
the :on=>:save|:update|:create option, as well as
validates_uniqueness_of are taken care of by AR:V, albeit by extending
AM:V"
http://www.ruby-forum.com/topic/158973

> Here's a crazy idea (not sarcasm; I realize it's quite possibly insane): When
> you build a framework like Rails, designed to aid in rapid development of an
> app, design it around building components, not whole applications. That is,
> design it around building gems -- possibly lots of tiny gems (would one per
> model be too much?) -- so that when it comes time to "extract functionality"
> from your app, you'll already know what depends on what, and what you'll need
> to disentangle.

There have been some forays into leveraging more advantage of gems in rails:

http://revolutiononrails.blogspot.com/2007/01/gem-based-development-process.html
http://ryandaigle.com/articles/2008/4/1/what-s-new-in-edge-rails-gem-dependencies
http://www.intridea.com/2008/6/11/gemplugins-a-brief-introduction-to-the-future-of-rails-plugins