Topic: Your preferred way to implement preferences?

Hi,

now, since I'm in the army (every Austrian has to go to the army for 6 month) I don't have
much time for developing and reading/posting here in the forum.

But now I have a question that interests me since I'm working on my own blogging system:

What's your preferred way to implement a preferences section.
Sample preferences would be: blog title, email notification yes/no, spam protection yes/no, ...

I did it the CRUD(create, read, update, delete)-like way, but without the C and D :-) :
A table Preferences with columns 'key' and 'value'. A model 'Preference'.

How would you implement this?

Regards
Dieter

My homepage: http://www.komendera.com/
Working at: http://www.abloom.at/
My blog: soaked and soaped http://soakedandsoaped.com/

Re: Your preferred way to implement preferences?

I wouldn't store the preferences as key/value pairs in the database. Instead I would create a column in the preferences table for each kind of setting (blog_title, email_notification). This way you can make each column the proper type (boolean, string, etc.) and you don't have to do any special magic to get the preference form fields hooked up. You can treate the preferences like any other model. It seems easier to fetch values this way too: (@preference.spam_protection?).

You can create a controller/helper method which fetches the first/deault preferences and just uset that:

def current_preference
  @current_preference ||= Preference.find(:first) || Preference.new
end

The only part about this I don't like is that you will only be needing one record in this database. It's a little weird, but I don't think this will cause any problems. The benefits far outweight the alternatives anyway.

You could go one step further and rename this preferences table to blogs. This will add a layer of abstraction so your Rails application can support multiple blogs, each with their own settings.

Railscasts - Free Ruby on Rails Screencasts

Re: Your preferred way to implement preferences?

The I've already seen the thing with the 'blogs' table in typo. They are doing it the same way. And as you said, I don't like that there will be just one record. And I don't intend to make my app multi-blog-ready.

But your way really has some advantages. I will overthink my implementation.
Thanks!

My homepage: http://www.komendera.com/
Working at: http://www.abloom.at/
My blog: soaked and soaped http://soakedandsoaped.com/

Re: Your preferred way to implement preferences?

I've been working over the same thing recently - I'd like to clean it up into fewer fields because my app is starting to have lots of fields with just true/false, or a single digit integer.  What I'm thinking of doing is store it either as sum (similar to how unix file permissions work), or as just a string of characters.  I'll probally go with the second one, then just make methods in the model to make these easily useable, basically just pull the specific character out and parse it however needed.  That way it can be a boolean (0 or 1) and int of whatever length, or a string of whatever length.  It's a little messy as far as looking at the raw database, but looking at the database ain't easy right now anyway w/ ascociations.

What do you guys think?
-Drew

Re: Your preferred way to implement preferences?

Whenever I do preferences, I do them as a key and value.  I don't like being forced to add a new column anytime I want to add a new preference, plus with keys and values I can do reporting on user preference settings (if there are many users who have preferences).

The ability to apply data types to preferences by storing them in their own column is nice, but I prefer the other approach anyway.  If you want to do some sanity checking on your preferences, you could always add helper methods to the object that has the preferences, or even create a has_one association and put the preference key in the conditions for that has_one.

Re: Your preferred way to implement preferences?

I'm curious what the preference form code looks like when using keys/values in the table instead of separate columns. Do you create a getter/setter methods for each "attribute" in the preference model? This way you can use form helpers. To me this is as much work as adding a column to the database, but maybe I'm wrong.

Railscasts - Free Ruby on Rails Screencasts