I'll admit it I'm not a 'good' coder. I was never employed as a programmer, but I did managed development projects as functional analysts
. I often got upset if the programmers didn't understand the specs (usually with good reason!) so I'd try to clarify the specs with steve code
, which was usually a hack!
I've used many hacks over the years for various reasons (e.g., I was not very familiar with a new language, I was not sure how I would implement what I was trying to do, etc). One of my favorite hacks is to use a serialized hash to define preferences/setting. The goal was to use the hack in development and then add the preferences to columns before production. I often did not accomplish that goal and just used the hash.
Preferences are usually data that seldom get changed, does not need to be queried etc. They may be used as an argument to a calculation, define how something is displayed, etc. I'll use a model Group
to explain how this is used. The Group
in my example of a Golf group that has many Players
and Games
. The purpose of the application is to compute a quota for each player (similar to handicaps). I have a number of Clubs/Groups that use the application to manage their information. The group has options that controll how these quotas are computed. They can use a different number of Rounds
and other options in the computation. They may throw out the high and low score in the computation. They may limit the score used in the quota computation for a new player.
My original scheme was to use three hashes in the process. One defined the default keys and values. One defined the casting (string, integer, boolean, etc) of each key/value and one, which is the serialized hash, merges and casts the input params. The default hash (scaled down version) may look like:
def default_options
options = {
limit_new_player:true,
limit_rounds:3,
limit_points:2,
sanitize_first_round:false,
rounds_used:10,
truncate_quota:true,
use_hi_lo_rule:false,
}.with_indifferent_access
end
The new scheme is to use the attributes API to replace the casting hash. Attributes are added for each key. A scaled down model (relations not present)
class Group < ApplicationRecord
# relations include Club, Players, Game, Round through Game and Users
after_initialize :set_attributes
serialize :preferences, Hash
attribute :limit_new_player, :boolean
attribute :limit_rounds, :integer
attribute :limit_points, :integer
attribute :sanitize_first_round, :boolean
attribute :truncate_quota, :boolean
attribute :rounds_used, :integer
attribute :use_hi_lo_rule, :boolean
def set_attributes
set_default_options if self.preferences.blank?
self.default_options.each do |k,v|
#TODO use self.has_attribute?(k) to raise exception if an attribute is not defined, but testing should catch it
self.send("#{k.to_s}=", self.preferences[k])
end
end
def set_preferences
self.default_options.each do |k,v|
self.preferences[k] = self.send(k)
end
end
def set_default_options
# set preferences to the default option if preferences blank (a new record)
self.preferences = self.default_options.to_h
end
def default_options
options = {
limit_new_player:true,
limit_rounds:3,
limit_points:2,
sanitize_first_round:false,
rounds_used:10,
truncate_quota:true,
use_hi_lo_rule:false,
}.with_indifferent_access
end
def update_group(params)
#called from the update method in the Groups controller, all attributes are in the group_params
self.assign_attributes(params)
# updates record without saving, just sets attributes
self.set_preferences
# now use the set attributes to update to serialized preferences and save
self.save
end
end
This may be still be a hack, but a lot cleaner one than my original scheme. The process if fairly simple
- On initialize the serialized preferences are moved to attributes
- Preferences are just like model attributes and used in computations/views (Current.group.rounds_used)
- Forms don't have to use xx_tags helpers
- You don't have to use Permit on hash for strong params
- Updating preferences acts like real attributes and the attributes are just moved to the serialized hash
I currently have 27 attributes in the current system. Beside the ones used in this post there are attributes that controller the scoring of a game, which team/player(s) won. Golf is a game of skill and games are really mini-tournaments where you pay and entry fee and you may get your money back (or more) if you win.
Top comments (0)