Booking Engine With Editable Associated Model

Rails
1

I’m creating a booking engine for personal trainers to make bookings
with their clients.

Each booking has_one workout template which in turn has_many
exercises.

When the personal trainer creates the booking I’d like them to be able
to edit the associated workout template as a completely fresh instance
of the template.

My current thinking is to use the vestal_versions[1] or paper_trail[2]
gem to make each booking a new version of the workout. I imagine I
would then reference either the version.id, updated_by or updated_at
in order to find the version in the future.

How far off the right approach am I? Is there a pattern I should be
digging into to understand this problem better?

I’m sure you can tell I’m new to Ruby/Rails and programming and any
help would be greatly appreciated.

[1] GitHub - laserlemon/vestal_versions: Keep a DRY history of your ActiveRecord models' changes
[2] GitHub - paper-trail-gem/paper_trail: Track changes to your rails models

2

On Jan 24, 2012, at 1:31 AM, Vladiim wrote:

My current thinking is to use the vestal_versions[1] or paper_trail[2]
gem to make each booking a new version of the workout. I imagine I
would then reference either the version.id, updated_by or updated_at
in order to find the version in the future.

I haven’t used Paper Trail, but Vestal Versions uses a version attribute
(integer) to track what version you’re currently at. It also allows you
to step back and forth through that trail. I don’t really think this
matches up with your metaphor. (As an aside, VV stores these versions as
YAML, so they’re not particularly searchable or available for
statistical analysis.)

How far off the right approach am I? Is there a pattern I should be
digging into to understand this problem better?

You might want to look at nested resources for this. A workout could
have many exercises. A new workout could be created with a set number
(and type) of exercises in it (either hard-coded in the controller or
following a template of some sort), and then you could remove some, add
some others, as needed. The workout then becomes the master record – I
would say that it belongs to the trainer and it also belongs to the
trainee, and it has a specific date when it took place. That way you can
look at statistics in fairly fine-grained detail later, and track the
number of instances of a particular exercise, etc.

I’m sure you can tell I’m new to Ruby/Rails and programming and any
help would be greatly appreciated.

You are welcome. Everyone here was a newbie once.

Walter

3

Excellent advice… I’m a fan of your idea of having nested resources
as I had a fear of massive versioning tables with my original
approach. I’ll give this a G-O.