Rails object structure for reporting metrics

Question

I've asked a couple of questions around this subject recently, and I think I'm managing to narrow down what I need to do.

I am attempting to create some "metrics" (quotes because these should not be confused with metrics relating to the performance of the application; these are metrics that are generated based on application data) in a Rails app; essentially I would like to be able to use something similar to the following in my view:

@metric(@customer,'total_profit','01-01-2011','31-12-2011').result

This would give the total profit for the given customer for 2011.

I can, of course, create a metric model with a custom result method, but I am confused about the best way to go about creating the custom metrics (eg total_profit, total_revenue, etc.) in such a way that they are easily extensible so that custom metrics can be added on a per-user basis.

My initial thoughts were to attempt to store the formula for each custom metric in a structure with operand , operation and operation_type models, but this quickly got very messy and verbose, and was proving very hard to do in terms of adding each metric.

My thoughts now are that perhaps I could create a custom metrics helper method that would hold each of my metrics (thus I could just hard code each one, and pass variables to each method), but how extensible would this be? This option doesn't seem very rails-esque.

Can anyone suggest a better alternative for approaching this problem?

EDIT: The answer below is a good one in that it keeps things very simple - though i'm concerned it may be fraught with danger, as it uses eval (thus there is no prospect of ever using user code). Is there another option for doing this (my previous option where operands etc. were broken down into chunks used a combination of constantize and get_instance_variable - is there a way these could be used to make the execution of a string safer)?

Answer 1

This question was largely answered with some discussion here: Rails - Scalable calculation model .

For anyone who comes across this, the solution is essentially to ensure an operation always has two operands, but an operand can either be an attribute, or the result of a previous calculation (ie it can be a metric itself), and it is thus highly scalable. This avoids the need to eval anything, and thus avoids the potential security holes that this entails.