Make this work with a preferences table

[scttymn]

Description

Right now we assume a field named after whatever model you are adding preferences to. For example, User expects to have user_preferences. It would be nice to have the option to have this work with a preferences table, so instead of a column, User has_many :user_preferences and everything "just works".

Assumptions

The preference table will have a name and a value column to store the preferences and their values.

Example

class User < ActiveRecord::Base
    has_many :user_preferences

    include Preferential
    pref_accessible :favorite_color

end

class UserPreference < ActiveRecord::Base
    belongs_to :user
end

[erichurst]

I'd like to see it work with a polymorphic Preference class. E.g. User has_many :preferences & Organization has_many :preferences.

[thmzlt]

"Yo dawg! I herd u like preference so I put a preference on your preference so u can have more preferences."

https://github.com/thmzlt/preferential

[erichurst]

@thmzlt nice, man. Many thanks. I discovered late last week that Preferential fails in Rails 3.2, but it's alright as 3.2 introduces ActiveRecord::Store: http://api.rubyonrails.org/classes/ActiveRecord/Store.html.

We've been chatting about how to adapt Preferential. Seems extending AR::Store, and adding some steroids would be helpful. We just don't know what that would be right now. Thoughts? What about you @scottymoon?

[scttymn]

Yeah, it was initially created to scratch the itch that ActiveRecord::Store does. I think to move it forward we need to take a step back and determine what we want out of it. An engine seems more appropriate for something that extends more than just data persistence. A library that possibly works with more ORMs than active record and more frameworks than Rails might be handy.

And for the record, @thmzlt, your code was smokin'. Great job.

[thmzlt]

I wish I could help more, but I don't know what the use cases look like. For instance, ActiveRecord::Store doesn't care about querying the data outside the context of a single object, so it might get in the way if you are querying sets of objects based on their preferences.

I forked the idea as an exercise on Rails engines, and I like that it takes care of copying migrations and helps with testing. However, I agree with @scottymoon in that Preferential should be application-agnostic logic.

I think a built-in controller and input validation would be good features to have. Let me know if I can help.

[scttymn]

I agree. I'm not sure what the use cases are. I'm a big fan of organic development and scratching our own itch. I don't want to make busy work, but extract tools that make things better/easier/faster/fun..er.