in a controller i can use request and params methods.
i know each controller is inheriting from ActionController::Base.
however, i cannot find these 2 methods in the api documentation for ActionController::Base http://api.rubyonrails.org
where are these methods defined? it would be great to know ALL methods that i can use in a controller.
thanks
request and params in ActionController:Base are shortcuts to the ActionController::Request object and its parameters method. It isn't well-documented, but you can see that by looking at the code for ActionController::Base.
Knowing that, you can find the documentation for these methods here:
http://api.rubyonrails.org/classes/ActionController/Request.html
Are you looking at the Rails 3 docs or the Rails 2 docs? I like to read the docs through this site: http://railsapi.com/doc/rails-v3.0.0.beta.3_ruby-v1.9/
If you go to the root, it lets you set your version of rails and ruby, so you have the right doc stack, with a good search feature etc. Maybe that will help :)
Related
I'm using the Apipie gem, which I find great in every way except it seems that I have to include my API documentation right inside my controller code, which IMO really hurts the easy navigability of the code. Is there any way to use Apiepie but have the documentation separate somewhow?
I'm trying to develop a Redmine Plugin, I started reading the documentation, and learning a lot of Ruby and a lot of Ruby on Rails. (I'm a PHP/Python/js guy)
Then I started looking through other plugins, and I found this code. I can't find enough information to fully understand how this line of code works:
Issue.send(:include, RedmineRequireIssueAllowedToChangeAssignee::Patches::IssuePatch)
I understand that inside IssuePatch are some things to override or add to Issue class.
Then I found this, explaining the use of send, and that confuses me, why not use just Issue.include?
The main question would be: where is this method include defined and what does it does?
UPDATE: related question
You can't just do include because it's a private method, so you use send which circumvents ruby visibility control. With send you can call any method, even private ones (as in this case).
where is this method include defined and what does it does?
It's defined as Module#include and, when invoked with a module as a parameter, it appends all instance methods of that module to the receiver (which is, in your case, Issue class). It's a very-very common idiom in Ruby.
I digg into some project with long development history
Maybe it's newbe question:
For specific controller I found thats it inherited from ActionController
like so
class GraphController < ActionController
end
and seems it used for API cause when I add some actions there they shown without layout
can anybody point me to some good article about ActionController usage.
I check documentation but can't find any good explanation for tats stuff
http://guides.rubyonrails.org/action_controller_overview.html contains a good description of ActionController basics.
I don't think Rails calls it an interceptor, but I don't know what to search for.
In Java/Spring, you can create Interceptors that are called before and after any controller action in the MVC framework. This makes it easy to add data to the model for every request, so you don't have to keep adding it to each of your 50 controllers.
I have to take a wild guess and say Rails has something to do achieve the same effect... but I have no idea what it is called.
Care to share? :)
What you are looking for is called Filters.
ActionController::Filters::ClassMethods
Rails Guide
I've read about HMVC (Hierarchic Model View Controller) and it's flexible structure.
Have a look at this picture:
http://techportal.inviqa.com/wp-content/uploads/2010/02/MVC-HMVC.png
I wonder if the Rails 3 plugins are the answer to HMVC in Rails 3?
Based on the comments to Toby's answer it seems that you would like to be able to have MVC apps used as a component within a new app. Rails Engines (See http://rails-engines.org) provides this functionality. You simply install the engines gem and place apps in vendor/plugins and its modles/views/controller are all accessible.
This does not really conform to HMVC where the controllers in the new app delegate to other controllers. But like Toby I do not see the advantage of that.
What is nice about the Engines approach is that you can over ride any of models in the plugin by just adding a version of the model to the new apps app/model folder (same applies for views and controllers)
I have overidden app/views/layouts to give my Authentication app/plugin the same look and feel as the application it is included in.
For Rails 3 Railtie takes the place of engines and is officially supported (and actually used - Action Mailer is a Railtie plugin. I have not used it myself yet though.
Check it out at http://edgeapi.rubyonrails.org/classes/Rails/Railtie.html
A nice write up on it is also here http://www.igvita.com/2010/08/04/rails-3-internals-railtie-creating-plugins/
Rails has had plugins for a long time.
I doubt there is a technical reason why a controller couldn't dispatch to another controller, passing the request object along a chain. I just don't know what you gain by doing so - the diagram looks like spaghetti.
To me it's a misuse of MVC. I would suggest it is much simpler and more maintainable to push logic into lower-level models and classes and create a single controller that fronts the this logic, rather than creating a chain of controllers.
In the Rails 3 blog post, DHH mentioned the Cells project. I haven't used it but I am going to check it out.
The cart example shows well how that kind of functionality might clean up your application code. Code which retrieves data should be placed somewhere in controller. In every action or in a before filter. The Cell seems to be much better solution.
Please look at this rubyonrails-talk post: https://groups.google.com/forum/#!topic/rubyonrails-talk/0c4TT7UOGCw