I am watching Code School Rails testing course. There is an instance of the class zombie. The zombie model has a method:
def avatar_url
...
end
Within the test, .rb file has the following:
z.avatar_url
When I call a method like this, how does Rails distinguish if I'm calling a controller or model method? I hadn't thought of calling a model method from other than a controller, and only like Model.method and not object.method.
If both my controller and my model have a method with the same name, how would Rails know which one to call?
Update:
Lets take the class String as example, it is not a model, right?
So I could say:
s = String.new
s.capitalize
If this call doesn't go to a model and not to a controller, where does it go then? Where would a class like String be defined in the Rails directory?
A method inside a controller can only be called via URL.
Example:
/things/super_action
Should call the def super_action inside ThingsController.
As for Model methods, they can be accessed anywhere. Just note if they are instance or class methods:
Model.ultra_method
This is a class method call, it is probably defined as def self.ultra_method.
m = Model.new
m.instance_method
This is a instance method call, and it is probably defined as def ultra_method.
UPDATE
String is a core class of ruby language. As is Array, Number, etc. In your example you are creating an instance of String and calling an instance method of the String class.
It seems like you're new to Ruby as well as Rails. In Ruby, a class is sort of like a description of a type of object (although the class itself is an object, too). Whenever there is a class defined, you can create new instances of it, as with String.new. Note that classes always have capitalized names.
Class methods are methods that work on the class itself. You can tell when a method is a class method because it will be attached to the capitalized name of the class (just like String.new). On the other hand, instance methods only work on an instance of the class, not on the class itself (eg str = String.new; str.capitalize!). Usually there are more instance methods than class methods, because instances are the things that you're actually working with (new is the most common class method you'll see).
As others have mentioned here, String is not a Rails model; it's a basic Ruby class. When you're working in Rails, you have access to all the regular Ruby classes as well as other classes and methods that are defined within Rails' source code. So String is not defined in Rails itself, but Rails does provide some useful instance methods for strings (eg str.to_date).
A model in Rails is really just a Ruby class. To understand the workings of a model, you should make sure you understand how Ruby classes work. What makes Rails models special is that they inherit from a class defined in Rails' source code known as ActiveRecord (any class in Ruby can inherit from another class, this is just one example of that). ActiveRecord has a number of class and instance methods, which are also available to your models because they inherit from ActiveRecord. For example, if you have a class (model) called Person, you can automatically use the Person.find(id) class method to look up a particular instance of the Person class in the database. You also have the person.save instance method to save the instance to the database.
All of this was confusing to me when I first started, so my best advice is to familiarize yourself with Ruby as you learn Rails.
You can call Model class/instance methods from anywhere in Rails. Model are just the mapping to your database and acts as a proxy for your database. When you are calling
z.avatar_url
you are calling a method on "z" model instance. So not matter from where you call it will always call the model's method.
If you define a method with same name in both controller and model, you would always be calling a model's method with model instance or model class. Controller methods are simply action in Rails they are never referred directly from anywhere. They are used for Rails routing.
Hope I am clear.
Related
I am working on a Ruby gem that will be a REST API wrapper.
What I would like to do is have a class that can be instantiated from the gem with a method similar to Rails/ActiveRecord 'where' method such that I can pass a SQL-like syntax in the method and have some JSON returned. Something like:
include 'my-gem'
test = MyGem::ClassExample.where('name like %test%')
# returns JSON object from REST API
My concern is if I were to include this gem into a Ruby on Rails application, would this 'where' method have a naming collision with ActiveRecord's 'where' or would the 'where' method be the one that I had defined in my class?
Basically, I think it should be okay, but I am scared of having to refactor a bunch of tests and rename a bunch of methods because of Rails magic/my ignorance.
By the way, I am not worried about sanitizing input, the REST API does not provide direct SQL/database access and it is a closed-source product. There is some configuration that needs to be done upfront that I have not included in this example, I just wanted to know if I could use this method name or if there were best practices/potential issues that I may be in conflict with.
Classes are namespaces.
If you define where on your own class and Rails defines where on another class you will not have a conflict. This is the case for both instance methods and class methods, which after all are just instance methods on the singleton class of the class.
However, if you were to define where on Object or another top-level class then you'll run into plenty of conflict because all classes are subclassing these classes.
When we navigate through pages in a rails app, inturn we call one of the functions defined in the controller class. Lets say we access localhost:3000/articles/new then new action (method) of the ArticlesController class is called/invoked.It's simple.
But what i can't figure out is that since ArticlesController class is a pure Ruby class with some methods and we need an instance of this class to call one of it's methods. But we never explicitly do that.
Then how the function call of any controllerclass is made possible ?
The controller is initialized automatically by rails. Specifically, this calls the action method on the controller class, which does the actual initialization.
The RouteSet generates instances of any controller on demand based on the needs of the ActionDispatch routing system. See here for how this is done.
So unless you are testing a controller directly, you can rely on the router to supply you with a controller instance. And if you are testing one directly, you should be using an ActiveController::TestCase to do this work for you.
This is a fairly basic Ruby/Rails question but I'm not sure why it makes a difference if you call a class of an object in some circumstances vs calling an instance of that object in different places of the framework.
Say you have a model e.g. Product and you call Product.new you have a new instance of the class. But if you have certain methods that are defined in the model I only seem to be able to access these if I call the Class rather than an instance e.g. Product.where(param, param). But I cannot call product.where(param, param) - why is this?
There are two types of methods: Class methods, and instance methods. You must call the appropriate method on the right object.
class Product
def self.foo
# class method, only callable on Product
end
def name
# instance method, callable on an instance of Product.
end
end
If you attempt to call an instance method on a class, or vice versa, you'll see an undefined method error.
To use someone else's analogy, imagine a house and a blue print; the class is a blue print for an object, while a house would represent the instance. An instance of that class will have its own set of attributes (wall colour, window type, etc...).
What would this mean?
p = Product.find(1)
p.where('something == 2')
That doesn't make any sense, you have an instance, what are you querying for? Good API design results in methods defined where they make sense.
Recently I had to add a method to Redmine's core class. I was unable to use inheritance, so I've done something like this:
require_dependency 'time_entry_query'
class TimeEntryQuery < Query
def my_new_method(foo, bar)
end
end
and it works perfectly - my method is added to all new objects. However, I've seen someone declaring the new method in their own module instead and then sending :include to class, so it become a mixin. Here's an example:
module Patches
module SomeClassPatch
def my_new_method
end
end
and somewhere in app's initialization:
SomeClass.send(:include, Patches::SomeClassPatch) unless SomeClass.include? (Patches::SomeClassPatch)
What's difference between these two methods and which one should I use?
There are two differences:
When you use a mixin, there is a clear place where your "patch" methods can live. If I wonder "Hmm, where's this my_new_method" coming from, and I look at, say, TimeEntryQuery.ancestors or TimeEntryQuery.instance_method(:my_new_method).owner, that will return Patches::SomeClassPatch. So I know I have to look for a file named lib/patches/some_class_patch.rb somewhere to find where it is probably defined. (I could try source_location as well, but that is not always reliable.)
Mixing in a module into a class makes the module the superclass of the class it is being mixed into. So, if there already is a my_new_method defined in TimeEntryQuery, your first option will overwrite it, whereas in your second option, your method will become the super method of that method. IOW: with your second option, your new method won't be called unless the already existing method calls super.
I am developing a Rails application and would like to understand when to use self.for.
Here is the code of a method that I would like to fully understand. If it is possible I would like to have an alternative to this code so it would make things more clear.
def self.for(facebook_id)
User.create_by_facebook_id(facebook_id)
end
self refers to the current object.
Within a class, self is used to define a class-level method.
class Foo
def self.for(facebook_id)
User.create_by_facebook_id(facebook_id)
end
end
defines a class method for in class Foo. It is invoked:
Foo.for(facebook_id)
You can google for class methods to learn more.
It could be that a part of Rails or a plugin/gem is expecting that some classes will have a class method "for" More context would be helpful in this regard.
What the method is doing
As is common for class methods, it is creating an instance of a class. For example, the ActiveRecord class has a class method "create" which attempts to create an instance of the model class that has been stored in the database. Thus User.create will return an instance of the User class that has been stored in the database.
In your example code, it is calling a class method "create_by_facebook_id" that is provided by the User class in the application.
Looks like the "for" method is being used for information hiding since all it's doing is making another method call (to User.create_by_facebook)
Added:
By the way, the default return value from Ruby methods is the value of the last statement. So your example method will return the user instance newly created from the supplied facebook_id.
It looks to me like self.for is just an alias for creating a user for a facebook id. I think self.for should actually be:
def self.for(facebook_id)
User.find_or_create_by_facebook_id(facebook_id)
end
That way it searches for the user with that facebook id, and if one isn't found, creates that record and returns it. Then, self.for means "return the user for this facebook id."
Short answer: self always refers to the current object. So within an instance method, self is the instance, within a class method, self is the class and within a class definition (like in your example), self is the class...
For more information on class methods and the code snippet you posted, see the answer by Larry K.
If that code is inside of a class named Foo, then the alternative could be:
def Foo.for(facebook_id)
User.create_by_facebook_id(facebook_id)
end
self in this context is necessary if you have some generic class level methods that you want to be able to use across multiple classes. You add them to a Module using self. to scope them (as you don't know the name of the actual class that they are going to a part of), then include that module as part of your class.