Sorry about the awkward phrasing of the title -- not quite sure of the best way to title this but here's what I'm seeing assistance with:
In a Rails app, let's say we've got a model for a Product, and one of the attributes of the product is Price.
On the admin side of my app, I'd like to be able to set a "default" price that could be referred to if any new Product created isn't assigned a Price. If a Product does have a value for Price, then it would be used.
This is, of course, an example -- and I ask this question because I've got to imagine this is a common pattern. This can be applied to any resource that might have user-configurable global defaults or resource-specific values.
In pure Ruby, this would be solved, I think, with a class variable, so I'd be able to define ##default_price within the Product class and be able to refer to Product.default_price if the instantiated object's value doesn't exist.
My research here has pointed me towards the rails-settings-cached gem, which would allow for something like MyApp.default_price, but I'm wondering if there's a more elegant (non-plugin) way to accomplish this within the base Rails framework.
Note I'd like to setup this structure in code, but I want to be able to define the actual values through my app (i.e. config files aren't the solution I'm looking for).
Can someone enlighten me with the Rails way of handling this?
ActiveRecord picks up default attribute values from the database schema. However, these are baked into the migration and table schema and not configurable.
If you want configurability, the pattern that I've used is a before_validation callback method to set a value if the attribute is blank, e.g.:
class Product < ActiveRecord::Base
before_validation :set_price_if_blank
validates :price, :presence => true # sanity check in case the default is missing
has_one :price
private
def set_price_if_blank
self.price = Price.default if self.price.blank?
end
end
class Price < ActiveRecord::Base
def self.default
##default ||= Price.where(:default => true).first
end
end
This assumes that your price table is populated with a row that has a default flag. You could achieve this, e.g. through a seeds.rb file. I've added a validation rule to make sure that you still get an error if no default exists. It adds robustness to your application.
Also note that it's best to use Integers or Decimals for price data, not floats. See this answer.
Related
Forgive my ignorance if I am missing something really trivial, I am very new to RoR.
Coming from Django background I remember models being like
class Post(models.Model):
title = models.CharField(max_length=100)
description = models.TextField()
both column name and field type are clearly specified.
Where as, when I write this rails command
> rails g model Post title:string description:text
all I get is
class Post < ActiveRecord::Base
attr_accessible :description, :title
end
Is there a way to write column names and field types while extending ActiveRecord::Base instead of having them only in the migration file?
Thanks, any help is appreciated
attr_accessible is deprecated and strong params replaces it functionality in the controller.
If you want to get a list of the schema information in your model file you can annotate it at the top of the file. This was best practices at some point, however I do not think it is used as much. I personally do not like this and just use the schema.
Post on best practices and annotating:
http://rails-bestpractices.com/posts/68-annotate-your-models
Gem to auto annotate:
https://github.com/ctran/annotate_models
The most wonderful thing about ActiveRecord is that you don't need to do any mapping, as all the fields are being automatically mapped using current schema. Of course default mapping can be overridden if needed, however this is a very rare case.
This approach is called "convention over configuration" and is present all over Rails - it assumes most common parameters for what you are trying to achieve so it saves a lot of unnecessary coding and mapping. It might feel weird at start, especially that you'll need to learn how to override those defaults, but I promise you are gonna love it when you get used to it. :)
Oftentimes, I come across a situation that kind of irks me because I don't feel like my solution for it is up to par.
Say that I have a User model. There can be two TYPES of users - admins and the regular folk. In this particular case, I've simply split User and Admin into separate models - fair enough.
In some cases when there are numerous types of the same model (Foo can be green, red, purple, yellow, etc)
I don't see much sense in dealing with 10 separate models like YellowFoo, GreenFoo, etc - so I add a "type" attribute to the model and then the code for, say, finding the correct object is simplified to User.where(:type => "some_type").
Is this an acceptable way of doing things in Ruby on Rails? Should the type be set to a be Symbol instead of a string so that User.where(:type => :some_type) looks prettier or is this a hack no matter how you look at it?
Same goes for views that I create. In the above example, there is an admin controller with a whole separate dashboard from the users, even though the code for the dashboard is more or less the same, with a few exceptions (but in the future, potentially far more different).
Is this an acceptable way of doing things or the newb way?
Thanks in advance!
type attribute is good enough to use it inside the model to separate different types of objects. But type attribute name itself used by Rails AR class method, so I'd suggest to use model name specified field type name like 'user_type' for User model to avoid conflicts.
Having defined model's types you can add very handy model's scopes and methods.
For example:
class Order
# I prefer to define type constants as camelized strings, but it would be probably
# better to use strings in downcase for localization purposes
ORDER_TYPES = (OrderTypePersonal, OrderTypeOrganization = 'Personal', 'Organization')
scope :personal, where(order_type: OrderTypePersonal)
scope :organization, where(order_type: OrderTypeOrganization)
def personal?; order_type == OrderTypePersonal end
def organization; order_type == OrderTypeOrganization end
end
# find all personal orders
personal_orders = Order.personal.all
# build new organization order
organization_order = Order.organization.new
# check order type
Order.find(14).personal?
# user order types as select
f.select :order_type, Order::ORDER_TYPES
I would suggest for different types/roles of users in our application, we can define a Role model.
We can define as the associations between User and Role as per our requirement. More basically,
In Role Model we will define
has_many :users
In User model we will define
belongs_to :role
A role will have multiple users. We can check each users role in User model
def has_role?(roleSymbol)
(role.role_name.underscore.humanize.downcase.to_sym == roleSymbol)? true :false
end
Here we can check the user has a role of "Admin" or "Normal" user.
For view parts we can check the user roles and can include separate partial for different types of users.
Trying to find the definitive answer on whether active record associations should be in the list of attr_accessible attributes.
I've seen
class Foo
attr_accessible :name
attr_accessible :bars
belongs_to :bar
end
also seen
attr_accessible :bars_id
want to know the proper way to be able to do Foo.new(name: 'name' bar: barvar)
As often the definitive answer is: "It depends™"
Only the attributes you want to mass-assign should be made accessible.
So if you want or need to do…
Foo.new(name: 'name', bar: barvar)
…then you simply have to make bar accessible.
In the end assign_attributes is called which does a simple send("#{attribute_name}=", attribute_value) after checking the accessibility of the attribute.
Some coding style aspects:
Often mass assignment happens when processing the param hash. At least that's where the security problems are lurking. There you rarely have a Bar object but more often a bar_id.
However if you work with model instances, most people prefer using the association methods (as #Andrew Nesbitt wrote) because that often has some advantages (automatic saving, automatic update of the association counterpart, cleaner code, …)
So there are reasons to have one or the other or both.
My personal opinion: One should not waste a lot of time on this topic since Rails 4.0 will have a better solution for parameter sanitizing. (See strong_parameters if you want it in Rails 3, too)
You can avoid needing to make bar_id accessible by using the association builder:
# singular (has_one)
foo = bar.build_foo(name: 'name')
# plural (has_many)
foo = bar.foos.build(name: 'name')
The only time you would need to make an association accessible is if you are using accepts_nested_attributes.
While you can avoid making bars_id (shouldn't that be bar_id?) accessible in your example, the question is if parts of your application still needs access to it. Using active_admin, I had to make the whatever_id accessible to make things work with relations.
I'm trying to construct a system in Rails where I've got a Project model with a "type" column, and I'm not sure whether if I should explicitly store the type as a string in the projects table, or if I should store a type_id instead. The thing is, I feel like it would be stupid to create a type model; Types cannot be created or destroyed, there are simply a fixed number of them. But if I don't create a model, the only other way I can think to do it would be to create a Type class in /lib which has a get_name(type_id) method, and this seems like total overkill.
If I decided to just store the string, I'd be using unnecessary space, and filtering by type would be weird.
Any thoughts?
If you're sure the types are a fixed set you can define some numeric constant in the Project model and just store these number in a column of your projects table.
Here an example (not tested of course) where I call the column category_id to avoid to use the type name that would cause problems as rjz said:
class Project < ActiveRecord::Base
# Project categories are constants
CHEAP_PROJECT = 1
SOUND_PROJECT = 2
GRAPHIC_PROJECT = 3
SECRET_PROJECT = 4
# Force project_category_id to be a valid category identifier
validates :category_id, :inclusion => {:in => 1..4}
# At this point you can use the constants
# Here an example of a scope to get the secret projects
scope :secret_projects, where(:category_id => SECRET_PROJECT)
end
Be sure to validate the category_id values to be one of which you defined.
Once you have these constans you can even use from other places using something like Project::SOUND_PROJECT.
I think is a solution pretty clear, but if your requirements change (they always change...) you have to create a model and insert these project categories maintaining these identifiers.
Lets say you have a model like the following:
class Stock < ActiveRecord::Base
# Positions
BUY = 1
SELL = 2
end
And in that class as an attribute of type integer called 'position' that can hold any of the above values. What is the Rails best practice for converting those integer values into human readable strings?
a) Use a helper method, but then you're force to make sure that you keep the helper method and model in sync
def stock_position_to_s(position)
case position
when Stock::BUY
'buy'
when Stock::SELL
'sell'
end
''
end
b) Create a method in the model, which sort of breaks a clean MVC approach.
class Stock < ActiveRecord::Base
def position_as_string
...snip
end
end
c) A newer way using the new I18N stuff in Rails 2.2?
Just curious what other people are doing when they have an integer column in the database that needs to be output as a user friendly string.
Thanks,
Kenny
Sounds to me like something that belongs in the views as it is a presentation issue.
If it is used widely, then in a helper method for DRY purposes, and use I18N if you need it.
Try out something like this
class Stock < ActiveRecord::Base
##positions => {"Buy" => 1, "Sell" => 2}
cattr_reader :positions
validates_inclusion_of :position, :in => positions.values
end
It lets you to save position as an integer, as well as use select helpers easily.
Of course, views are still a problem. You might want to either use helpers or create position_name for this purpose method
class Stock < ActiveRecord::Base
##positions => {"Buy" => 1, "Sell" => 2}
cattr_reader :positions
validates_inclusion_of :position, :in => positions.values
def position_name
positions.index(position)
end
end
Is there a good reason for the app be converting the integer to the human readable string programmatically?
I would make the positions objects which have a position integer attribute and a name attribute.
Then you can just do
stock.position.name
#HermanD: I think it's a lot better to store the values in an integer column rather than a string column for numerous reasons.
It saves database space.
Easier/faster to index on an integer than a string.
Your not hard coding a human readable string as values in a database. (What happens if the client says that "Buy" should become "Purchase"? Now the UI shows "Purchase" everywhere but you need to keep setting "Buy" in the database.)
So, if you store certain values in the database as integers, then at some point, you're going to need to show them to the user as strings, and I think the only way you can do that is programatically.
You could move this info into another object but, IMHO, I'd say this is overkill. You'd then have to add another database table. Add another 'admin' section for adding, removing and renaming these values and so on. Not to mention that if you had several columns, in different models that needed this behavior, you'd either have to create lots of these objects (ex: stock_positions, stock_actions, transaction_kinds, etc...) or you'd have to design it generically enough to use polymorphic associations. Finally, if the position name is hard coded, then you lose the ability to easy localize it at a later date.
#frankodwyer: I'd have to agree that using a helper method is probably the best way to go. I was hoping their might be a "slicker" way to do this, but it doesn't look like it. For now, I think the best method is to create a new helper module, maybe something like StringsHelper, and stuff a bunch of methods in their for converting model constants to strings. That way I can use all the I18N stuff in the helper to pull out the localized string if I need to in the future. The annoying part is that if someone needs to add a new value to the models column, then they will also have to add a check for that in the helper. Not 100% DRY, but I guess "close enough"...
Thanks to both of you for the input.
Kenny
Why not use the properties of a native data structure? example:
class Stock < ActiveRecord::Base
ACTIONS = [nil,'buy','sell']
end
Then you could grab them using Stock::ACTIONS[1] #=> 'buy' or Stock::ACTIONS[2] #=> 'sell'
or, you could use a hash {:buy => 1, :sell => 2} and access it as Stock::ACTIONS[:buy] #=> 1
you get the idea.
#Derek P. That's the implementation I first went with and while it definitely works, it sort of breaks the MVC metaphor because the model, now has view related info defined in its class. Strings in controllers are one thing, but strings in models (in my opinion) are definitely against the spirit of clean MVC.
It also doesn't really work if you want to start localizing, so while it was the method I originally used, I don't think it's the method for future development (and definitely not in an I18N world.)
Thanks for the input though.
Sincerely,
Kenny
I wrote a plugin that may help a while ago. See this. It lets you define lists and gives you nice methods ending in _str for display purposes.