Using Rails 3.2.17. I have the following in my model:
class Shop < ActiveRecord::Base
before_create :set_next_position
private
def set_next_position
self.position = self.class.where(country_id: country_id).
maximum(:position).to_i + 1
end
end
self is a Shop object. Note the line self.class.where... which is equivalent to Shop.where.... In this case, I don't know what is the best practice - to use Shop.where... or self.class.where...? It is code smell to me.
I would say self.class.where is better than Shop.where inside the class body. This way, you won't have to change inside, if for some reason you want to rename the class and so on.
The only difference that I now about is in case of inheritance. When you have:
class Base
def self.example
42
end
def run_example
Base.example
end
end
class A < Base
def self.example
'not 42'
end
end
A.new.run_example
=> 42
So when don't have inheritance I prefer Base.example. In the other case self.class.example.
Related
I have a model directory structure like this:
/alerts
base_alert.rb
panic_alert.rb
hardware_alert.rb
alert.rb
With the /alerts/x_alert.rb models setup like this:
class base_alert < ActiveRecord::Base
...
end
class panic_alert < base_alert
...
end
class hardware_alert < base_alert
...
end
etc.
Is there any way to call create on alert.rb in the top directory, and, based on a parameter passed, it would create one of the children instead of alert.rb.
I.E. Alert.create({type:"panic_alert"})
And it would create and return one of the panic_alert types of alerts?
By making few changes to the class definitions, like subclassing the Alert from ActiveRecord::Base rather than BaseAlert, you could achieve what you are trying to accomplish.
Following are the updated classes:
# app/models/alert.rb
class Alert < ActiveRecord::Base
end
# app/models/alerts/base_alert.rb
module Alerts
class BaseAlert < ::Alert
end
end
# app/models/alerts/panic_alert.rb
module Alerts
class PanicAlert < BaseAlert
end
end
# app/models/alerts/hardware_alert.rb
module Alerts
class HardwareAlert < BaseAlert
end
end
Following are few ways to create the subclasses from the base class:
#panic_alert = Alert.create!(
type: 'Alerts::PanicAlert', #this has to be string
#other attributes
)
#alert = Alert.new
#alert.type = 'Alerts::PanicAlert' #this has to be string
# assign other attributes, if necessary
#alert.save
#alert = Alert.new
#panic_alert = #alert.becomes(Alerts::PanicAlert) #this has to be class
# assign other attributes, if necessary
#panic_alert.save
You can use the constantize or the safe_constantize methods to do that. What they do is take a string and try to return the class the string refers to. For instance:
"BaseAlert".safe_constantize
=> BaseAlert
or
def method_name(alert_type)
alert_type.safe_constantize.create()
end
The difference between the two is constantize will throw an error if there isn't a match for the string, while safe_constantize will just return nil. Remember, if you pass in a underscored string (say panic_alert) then you would have to camelize it.
What seems like a lifetime ago I created StiFactory for this. That said, I don't find much use for STI these days (hence the lack of maintenance).
say I have this serializer
class FooSerializer < ActiveModel::Serializer
attributes :this, :that, :the_other
def this
SomeThing.expensive(this)
end
def that
SomeThing.expensive(that)
end
def the_other
SomeThing.expensive(the_other)
end
end
Where the operations for the individual serialized values is somewhat expensive...
And then I have another serializer that whats to make use of that, but not return all of the members:
class BarSerializer < FooSerializr
attributes :the_other
end
This does not work... BarSerializer will still have this, that, and the_other...
How can I make use of inheritance but not automatically get the same attributes? I am looking for a solution other than module mixins.
Turns out the answer to this is to make use of the magic include_xxx? methods...
class BarSerializer < FooSerializer
def include_this?; false; end
def include_that?; false; end
end
This will make it only serialize "the_other"
Make the BarSerializer the parents class and put the method the_other in it. FooSerializer will inherits only the method and the attribute defined in BarSerializer.
I have a model base_table, and I have a extended_table which has extra properties to further extend my base_table. (I would have different extended_tables, to add different properties to my base_table, but that's non-related to the question I'm asking here).
The model definition for my base_table is like:
class BaseTable < ActiveRecord::Base
module BaseTableInclude
def self.included(base)
base.belongs_to :base_table, autosave:true, dependent: :destroy
# do something more when this module is included
end
end
end
And the model definition for my extended_table is like:
class TennisQuestionaire < ActiveRecord::Base
include BaseTable::BaseTableInclude
end
Now I what I want is the code below:
params = {base_table: {name:"Songyy",age:19},tennis_ball_num:3}
t = TennisQuestionaire.new(params)
When I created my t, I want the base_table to be instantiated as well.
One fix I can come up with, is to parse the params to create the base_table object, before TennisQuestionaire.new was called upon the params. It's something like having a "before_new" filter here. But I cannot find such kind of filter when I was reading the documentation.
Additionally, I think another way is to override the 'new' method. But this is not so clean.
NOTE: There's one method called accepts_nested_attributes_for, seems to do what I want, but it doesn't work upon a belongs_to relation.
Any suggestions would be appreciated. Thanks :)
After some trails&error, the solution is something like this:
class BaseTable < ActiveRecord::Base
module BaseTableInclude
def initialize(*args,&block)
handle_res = handle_param_args(args) { |params| params[:base_table] = BaseTable.new(params[:base_table]) }
super(*args,&block)
end
private
def handle_param_args(args)
return unless block_given?
if args.length > 0
params = args[0]
if (params.is_a? Hash) and params[:base_table].is_a? Hash
yield params
end
end
end
end
end
I'm using Single Table Inheritance using the following structure:
class Business < ActiveRecord::Base
end
class Restaurant < Business
end
class Bar < Business
end
and wanted to get a list of subclasses as a string array, so for Business -> ['Restaurant', 'Bar']
Any ideas on how I would go about this?
Here's one way to handle it.
Opinion I personally like this approach because the parent can define specific behavior or configuration when a child class is inheriting from the parent
class Business
##children = []
def self.inherited(klass)
##children << klass
end
def self.children
##children
end
end
class Restaurant < Business; end
class Bar < Business; end
Let's see it work
Business.children
#=> [Restaurant, Bar]
You can do:
Business.descendants.map {|klass| klass.name.demodulize } #generally I nest descendant in the main class namespace, hence the demodulize
Btw, due to Rails dev environment principles, you could have issues when developing.
Example, if you use a scope: Business.a_scope you could encounter issues.
It's known and the known way to proceed id to add at the bottom of your main class (Business here) something like:
your_children_types.each do |type|
require_dependency "#{Rails.root}/app/models/#{ path_to_your_child(type) }"
end
Don't have the reputation to comment on #naomik's answer, but if you're using Rails please remember to also add 'super' after your additions to the inherited method, like:
def self.inherited(klass)
##children << klass
super # this is 'super' important to not wipe out Rails' descendant tracker
end
I have a function that does this:
def blank_to_negative(value)
value.is_number? ? value : -1
end
If the value passed is not a number, it converts the value to -1.
I mainly created this function for a certain model, but it doesn't seem appropriate to define this function in any certain model because the scope of applications of this function could obviously extend beyond any one particular model. I'll almost certainly need this function in other models, and probably in views.
What's the most "Rails Way" way to define this function and then use it everywhere, especially in models?
I tried to define it in ApplicationHelper, but it didn't work:
class UserSkill < ActiveRecord::Base
include ApplicationHelper
belongs_to :user
belongs_to :skill
def self.splice_levels(current_proficiency_levels, interest_levels)
Skill.all.reject { |skill| !current_proficiency_levels[skill.id.to_s].is_number? and !interest_levels[skill.id.to_s].is_number? }.collect { |skill| {
:skill_id => skill.id,
:current_proficiency_level => blank_to_negative(current_proficiency_levels[skill.id.to_s]),
:interest_level => blank_to_negative(interest_levels[skill.id.to_s]) }}
end
end
That told me
undefined method `blank_to_negative' for #
I've read that you're "never" supposed to do that kind of thing, anyway, so I'm kind of confused.
if you want to have such a helper method in every class in your project, than you are free to add this as a method to Object or whatever you see fits:
module MyApp
module CoreExtensions
module Object
def blank_to_negative
self.is_number? ? self : -1
end
end
end
end
Object.send :include, MyApp::CoreExtensions::Object
There are a few options:
Monkey-patch the method into ActiveRecord and it will be available across all of your models:
class ActiveRecord::Base
def blank_to_negative(value)
value.is_number? ? value : -1
end
end
Add a "concern" module which you then mix into selected models:
# app/concerns/blank_to_negate.rb
module BlankToNegate
def blank_to_negative(value)
value.is_number? ? value : -1
end
end
# app/models/user_skill.rb
class UserSkill < ActiveRecord::Base
include BlankToNegate
# ...
end
Ruby Datatypes functionality can be extended. They are not sealed. Since you wan to use it in all places why not extend FIXNUM functionality and add a method blank_to_negative to it.
Here's what I ended up doing. I put this code in config/initializers/string_extensions.rb.
class String
def is_number?
true if Float(self) rescue false
end
def negative_if_not_numeric
self.is_number? ? self : -1
end
end
Also, I renamed blank_to_negative to negative_if_not_numeric, since some_string.negative_if_not_numeric makes more sense than some_string.blank_to_negative.