ActiveModel: Autoloading Digression
Having just returned from vacation I now continue my read through of the Ruby on Rails source code by looking at Active Model.
With this series of posts I’m going to do things a little differently, you see, I’ve already read all of Active Model but haven’t written anything yet. I want to take a more structured approach as I write these articles which will hopefully make it a good entry point for others looking for a more thorough overview of how Rails works.
Sound good? Alright, let’s dig in!
What is ActiveModel?
If you are relatively new to Ruby on Rails, it is possible that you may be asking yourself whether I have a typo in my header and actually meant Active Record.
No worries, Active Model is more of an abstract interface that is meant to describe the common pattern of interfacing with Action Pack, that is, the V and C parts of MVC. Active Record thus implements Active Model’s interfaces as well as add a host of unique functionality.
Active Model provides a known set of interfaces for usage in model classes. They allow for Action Pack helpers to interact with non-Active Record models, for example. Active Model also helps with building custom ORMs for use outside of the Rails framework. Rails Docs
So what you will see here with Active Model is a common set of things that need to be implemented by every ORM designer, such as Mongoid and MongoMapper, as well as Gems that have a storage related purpose (like Paperclip and Carrierwave).
This means our study of Active Model will be a good first step to being able to make sense of the pretty sprawling code base which is Active Record.
The table of contents, if you will, is found in the top level file that defines this module. Within we find a DSL of sorts, for requiring the different component modules through an autoload mechanism defined in Active Support.
Here it is:
The autoload mechanism is pretty neat actually so let’s take a look at that first.
@_eager_autoload is set (which happens in an
block, we throw the constant and path to load it into the
Finally, when we call
eager_load! it only loads the modules we have
specifically designated in eager blocks.
What isn’t immediately clear is how it handles those that are not eager autoloaded. This is found in Active Support:
While there is a whole lot more code than what I’ve snipped here, this should give you a trail to follow to understand how it works.
Basically we hook into Object, Module, and Exception and include these Active Support dependency resolution modules. In the case of Module, we include ModuleConstMissing, which has some very interesting logic in it that ultimately decides whether the file can be loaded, is unable to be loaded, or requires other files to be loaded along with it. It’s an interesting read.
Very clever bit of lazy loading of constants, nicely done Rails!
That is enough for today, next up, the table of contents of Active Model.