Re: [ruby-81] Design question...

From: Billy
Sent on: Wednesday, August 22, 2007 10:57 AM
Good morning, Sam

The way I would accomplish this is create a single table called 'Settings' (or whatever), that looks something like:

create table settings (id integer primary key auto_increment, setting1 varchar(126), setting2 tinyint, setting3 text)

and inside of your Setting model, define validation levels. Each level will represent a chunk of validation, depending on where in your flow you are:

attr_accessor :validation_level
validates_length_of(:setting1, :maximum => 32, :allow_nil => true, :if => Proc.new { |s| s.validation_level == 1 })
validates_presence_of(:setting2, :if => Proc.new { |s| s.validation_level == 2 })
validates_length_of(:setting3, :maximum => 120, :allow_nil => true, :if => Proc.new { |s| s.validation_level == 2 })

Then any time you do a save to the model, you simplly do:
settings.validation_level = 2

I use this pattern in a  few places and it works pretty well. Good luck.

On 8/22/07, Sam Pierson <[address removed]> wrote:
Hey folks,

I have had a simple design issue that I've been kicking around for a while that I have yet to find an elegant solution for.  I wonder if you could help:

The scenario:

I have an application that has a bunch of miscellaneous settings.
These settings must be editable by an administrator via web pages.
The settings are mostly unrelated, and some are dangerous and require a lot of explanation, so need to be on a page of their own.  I'll repeat that, because it is a key issue: setting editing will be spread across several web pages.

The problem:

How do I structure a table/model to store these settings, allow them to be individually retrieved/saved, and be appropriately validated?

Solution 1:

Create a settings table with a column for each different setting.

Pros: I can add appropriate validation for each column.

Cons: All settings have to retrieved/saved simultaneously, i.e. I need to have valid data in all attributes for the model to validate. If I have 4 pages of settings, and there are no "default" values I can use, this is not possible.

Solution 2:

Create a generic Setting table/model with attrs "name" and "value".

Pros: Very flexible.  Settings can be gotten/saved individually.

Cons: Can't add validation to the model, or if I do there has to be some big switch statement in the validate() routine to decide what to validate.  Clunky.

Solution 3:

Create a separate table/model for each setting.

Pros: Settings can be gotten/saved individually. Appropriate validation can be added to each model.

Cons: It seems retarded to create 40 tables/models to hold 40 different settings.  Inelegant.

Summary:

As you can see I have yet to find an elegant answer to this.
Can anybody point me in the right direction based on their experience?

Thanks,

-Sam.




--
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ( [address removed])
This message was sent by Sam Pierson ([address removed]) from The East Bay Ruby Meetup Group.
To learn more about Sam Pierson, visit his/her member profile
To unsubscribe or to update your mailing list settings, click here

Meetup.com Customer Service: [address removed]
632 Broadway New York NY 10012 USA

Our Sponsors

People in this
Meetup are also in:

Sign up

Meetup members, Log in

By clicking "Sign up" or "Sign up using Facebook", you confirm that you accept our Terms of Service & Privacy Policy