I have created a module in order to implement a common controller action: order
When I define the method I want to check if the controller that has included the module, responds to a specific method (authorize_respond).
How can I achieve that?
Find below my current implementation that doesn't work (never calls the method authorize_ordering).
def order
send(:authorize_ordering) if self.respond_to?(:authorize_ordering)
ordering = params[:ordering]
...
end
Embarrassing, never mind.
Method authorize_ordering was protected. Being public works as expected.
Related
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.
I am confused on how this library works:
The ApplicationController has a private method called selected_account() as you can see here: ApplicationController
Then, from another Controller which is a child from ApplicationController, we do an action that does this:
def index()
#selected_account = selected_account
graph = get_accounts_graph()
#accounts = Account.get_accounts_map(graph)
end
How can we do that? Isn't it out of scope?
This will be confusing for those who come from java or c# world. But here is a decent explanation
In Ruby, the inheritance hierarchy or the package/module don't really
enter into the equation, it is rather all about which object is the
receiver of a particular method call. When a method is declared
private in Ruby, it means this method can never be called with an
explicit receiver. Any time we're able to call a private method with
an implicit receiver it will always succeed. This means we can call a
private method from within a class it is declared in as well as all
subclasses of this class
It might be confusing at first, but in Ruby private does not mean what it means in Java/C++. Ancestors can call private methods just fine.
What private actually means is that you cannot call the method with an explicit target. That is, if foo is private, you can call it with foo(), but not with self.foo() or obj.foo(). That way you can call private methods only on yourself.
Furthermore, Ruby has protected. The semantics are again different from Java/C++ – protected methods can only be called from instances of the same class. It is rarely used.
The child controller inherits from ApplicationController so it can call internal private methods on itself without issue. There is no scoping problem. The subclass inherits all the public/private/protected methods of its super class.
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.
Watching this video by Yehuda, and he gave this snippet about how Ruby helps you build better abstractions.
class FOWA
def self.is_fun
def fun?
true
end
end
is_fun
end
He was talking about, in ruby, how if you are repeating code in your class over and over again, you can abstract it out without having to think about things in terms of methods etc. And he said this was using a metaprogramming technique.
Can someone explain what this is?
It is a class method on FOWA (so its like a static method, you don't need an instance to call it), and this class method is really just wrapping another method that returns true.
And this is_fun class method is now being executed or what? not sure what the last line "is_fun" is doing?
http://vimeo.com/11679138
The is_fun call at the end of the class calls the static method. The static method then defines the fun? method inside of the FOWA class. Then, you can do this:
f = FOWA.new
f.fun?
If you take out the is_fun call at the end of the class, the fun? method doesn't get defined.
He mentioned that you wouldn't use it in this way, but the point is how easy it is to dynamically add a method to a class. You might use it like this if you wanted the method to be available in subclasses and you wouldn't call is_fun in FOWA, but you might in a subclass. It gets a little more interesting if you have a parameter for is_fun and the definition of fun? changes depending on that parameter.
This also leads right into modules because you can define a module with the same is_fun method and then just have your class extend the module and the methods in the module are available in the class. You would use this technique if you want your method to be available to more than just subclasses of FOWA.
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.