keeran.com

I’ve been working quite a while on this prototype project now and I’m quite happy to admit that the majority of the work has been an exercise in wrapping up a scaffolded application into something more presentable and usable for the target audience. This post is going to try and describe what I think could work for future applications in the style of a Rails Recipe.

Problem Description

As I’ve gone through the process of making tweaks and alterations to the main scaffolded files to achieve what I’ve wanted, I’ve realised that while hooking together sets of scaffolds can get you so far – presenting the user with an intuitive navigation for accessing these scaffolds could be the main stepping stone in moving from scaffolds to a first demonstrable prototype.

For most applications the user will be aware of some top level CRUD feature (or set of features) which will guide their use through the rest of the application. Even DHH himself is suggesting we embrace the ‘CRUDness’ of our applications, so I think our navigation should be able to automatically represent the model structure and hierarchy of our system.

Essentially what I would like is a helper that can take the current controller or action and, based on our model structure, suggest appropriate related controllers to access and provide a way of navigating the hierarchy of our system. If everything is CRUD-based this should result in natural learning and use of the system, especially if the user is already familiar with the hierarchy of a domain, e.g. the application is to supplement or replace an existing set of processes.

The Solution

My suggestion is that we extend ActiveRecord::Base to provide the extra functionality I would like. If we modify the class by way of a Mixin, we can add functionality to the class and assume that any future derived classes (Models) will share this functionality.

Let’s set up an example to follow – below is a set of models which make up part of a system.

Quite a simple set of relationships to begin with. As far as foreign records are concerned a Spend record is composed of the Service we are spending on and the Currency of the spend.

Using Ruby Reflection to access associated models

ActiveRecord has a method of querying the class itself to return all associations – this is how the rails code can determine what tables to join etc when performing queries. The ActiveRecord API for reflection tells us that the method reflect_on_all_associations can return an array of AggregateReflection objects. The base class of the AggregrateReflection (MacroReflection) is where we can find the information we want – the class of the associated models.

The code below shows how you can wrap up these method calls into something more friendly. I don’t really want to be handling these kind of objects regularly in my code anyway!

I’m sure there is a much cleaner way to handle the array processing and output, probably in the form of aggregate_objs.map {|m| m.klass}, but when I wrote the code I was still struggling with getting my blocks working properly, so I keep track of my returns with a variable called ‘out’ just in case.

So now, if you put all that code into IRB (after requiring active_record.rb and active_support.rb), you should be able to run the following:

Air Guitar! Now we have a workable array of classes to play with. Unfortunately this is limited to working with the Spend class, which is pretty useless. Now we’re going to bolt this functionality onto the AR::Base class so that all of our models can be queried in the same way. We will do this with a Mixin.

Extending ActiveRecord with a Mixin

Coming soon…I’ve decided to split this into 2 or 3 parts otherwise It’s going to take me til the end of the week before I get anything online. Release early!