in my application, I have a "User" model. Each user can have multiple (email) addresses which are defined in the model "Address":
Class User < ActiveRecord::Base
has_many :addresses
def is_authorized(op)
# returns true or false
end
def is_owned_by(user)
# returns true or false
end
end
Class Address < ActiveRecord::Base
belongs_to :user
end
Inside the AddressController class, the currently logged in user is available in the "#user" instance variable. The controller prevents ordinary users from editing, deleting, viewing etc. addresses which don't belong to them - but he does allow an administrative user to edit those. The AddressController class can ask the AddressModel if the user currently logged in is performing normal or superuser operations.
This all works nicely and database updates are made as expected, however, I'd really like to have different HTML views depending on the mode of operation. I can only think of two ways to achieve that:
Make the mode of operation (normal/privileged) known in the AddressController class (using an instance variable, e.g. #privileged) and use an "if" statement in the view.
Use something like an "after_filter" in the address controller to render a different layout.
If it is possible to display the results of executing a single controller in two completely different layouts, depending on it's mode of operation, what is a good way to achieve that?
Thanks in advance
Stefan
You can specify which view to use to display the result of an action in the action itself. You can also specify which layout to use too. So, for example:
def my_action
if #user.is_authorised(...)
render :action => 'admin_action', :layout => 'admin'
else
render :action => 'non_admin_action', :layout => 'non_admin'
end
end
This will render either admin_action.html.erb or non_admin_action.html.erb depending on the returned value from is_authorised. The :layout option is, er, optional and refers a layout in views/layouts. There are various other options the render call which you can find in the documentation for render.
You can specify the layout of the view for that particular controller, or the whole application in the application controller by:
class SomeController < ApplicationController
layout :set_layout
def set_layout
#user.is_authorized(...) ? "privileged_layout" : "normal_layout"
end
...
end
You can try to figure it out here: http://guides.rubyonrails.org/layouts_and_rendering.html#using-render, under 2.2.12 Finding Layouts
Hope this helps =)
You can simply call the render method manually at the end of your controller action:
if #privileged
render :action => 'show_privileged'
else
render :action => 'show'
end
This will render app/views/myview/show_privileged.html.erb or app/views/myview/show.html.erb. Alternatively, you can use the :template option to give an explicit template file to the render method.
If this is the only controller in your app where you're if/else'ing all over the place that's probably fine. If you start doing this type of logic everywhere that should tell you that you're doing too much at once.
The answer you accepted (which is fine and works!) has a different layout and a different view, to me that says the controller is doing too much - I'd split this out into an admin controller.
You should put administrative actions in an an administrative namespace and restrict it there. Create a directory called admin in your controllers directory and add an _application_controller.rb_ in there:
class Admin::ApplicationController < ApplicationController
before_filter :check_authorized
private
def check_authorized?
if !logged_in? || !current_user.admin?
flash[:notice] = "You've been very bad. Go away.
redirect_to root_path
end
end
end
Now you can put controllers into this namespace and make them inherit from Admin::ApplicationController too.
Related
I have a rails app where I am wanting to make the landing page dynamic so that every time the user goes to it it changes.
I have cafe's in my app, and each cafe has its own show page. I want each show page to be dynamic. The url's are based off of the cafe's id, so I figured I'd have to use those IDs as the focal point for creating the dynamic work i'm looking for.
In my cafe's controller I have
class CafesController < ApplicationController
def root
array = Cafe.pluck(:id)
array.sample
end
end
in my routes file I have
root 'cafes#root'
The error I'm getting is
`CafesController#root is missing a template for this request format and variant. `
Would anyone know what I am missing with this one? Much appreciated.
I image you could do something like:
class CafeController < ApplicationController
def root
redirect_to Cafe.all.sample
end
end
By the way, this approach has the benefits of letting you keep and use all your normal routes in the conventional manner.
Also, you might consider calling this action something a little more descriptive. Perhaps something like random_cafe. IMO, root 'cafes#random_cafe' is a bit more understandable.
missing a template error because you have to specify a template to render, I'm imagining that array.sample will return something like /cafes/firstsampe.html.erb where firstsampe.html.erb persists inside cafes views folder so you can use it like this redirect_to :template => array.sample.
Hope it helps.
I don't have any idea about what your data looks like, but there are two approaches you can take here:
Show a random cafe when the user hits your home page (root)
Redirect a user to a cafe's page randomly when they hit the home page
In scenario 1:
Controller:
class CafesController < ApplicationController
def index
#cafe = Cafe.order("RANDOM()").first
end
end
Routing:
root 'cafes#index'
Views:
app/views/cafes/index.html.erb
<p><%= #cafe.name %></p>
In scenario 2:
Controller:
class CafesController < ApplicationController
def index
redirect_to cafe_path(Cafe.order("RANDOM()").first)
end
def show
#cafe = Cafe.find(params[:id])
end
end
Routing:
root 'cafes#index'
resources :cafes, only: [:show]
Views:
app/views/cafes/show.html.erb
<p><%= #cafe.name %></p>
Perhaps this can even become a Community Wiki, but I would love a detailed description of how the controller works - or rather, how I can get it to do what I want it to do.
I understand the general structure of MVC and how the model stores the db structure, and the controller interacts with the db and passes info to the view.
However, I am puzzled (on a fundamental level) about how to accomplish simple tasks using my controller. I know that if I want to create a new record for a model/object, I just do object = Object.new(:name => "Object Name") in the Rails console.
But how on earth would I do that in the CRUD elements of the controller and why?
Please use a simple example - e.g. showing a user the balance of their bank account (I know there are many complexities surrounding this, but ignore them for the sake of this explanation). What would the model look like (just include: Name, Address, Transaction Type (Deposits/Withdrawals), Balance).
What would a view look like? What would the controller look like? Any choices you make (like using a form) please explain them. Why would you use a form, as opposed to a drop down menu and (in layman terms) how does the form or drop down menu interact with the controller? How do I get the info captured there to the db and why am I doing it that way?
I know this sounds like a lot to ask, but I have done RailsTutorial.org, watched many Railscasts, read the Rails guides, and read many other tutorials and still have some basic gaps in my understanding of the way Rails works and why.
Thanks in advance.
I don't know how much more help I can be, but I understand your pain having just come to rails myself. The article recommended by ghoppe, "Skinny Controller, Fat Model" explains the function of Ms Vs & Cs nicely. Seeing as that does not fully answer your question I will try to explain the mechanics of each structure.
Model
class Account < ActiveRecord::Base
belongs_to :user
validates_presence_of :address
def name # Account does not have a name field, but User does so I will make a name method for Account and feed it name of the user it belongs to.
user = self.user # Account gets the user method with the <belongs_to :user> association
# note: Rails expects Accounts to have a user_id field so it can perform the "magic" to associate Accounts with Users
if user.name
return user.name
else
return nil
end
end
end
The model describes your object. Like an object in any OOP language you want to put all of your object logic here. This includes the rails helpers for association(has_one, belongs_to, ...) and validation, as well as any other method or library you want the object to be able use throughout your Models Views and Controllers.
Controller
class AccountsController < ApplicationController
before_filter :name, :only => :edit, :destroy # #account.name will be executed before the edit or destroy method(action) can be invoked on #account. If the user who has the account has a name the action will execute.
def index # This is a RESTful action and is mapped by Rails by default to an HTTP GET request. Rails expects an index.html.erb or index.haml.erb or index.something in the Accounts view to map this action to.
#accounts = Account.all # #accounts is an instance variable and will be accessible in the view this action is mapped to.
end
def show
#account = Account.find(params[:id]) # params[:id] is passed to the controller from the view. The params hash is the primary tool form moving data from a form or URL into a controller. Anytime you click on the link_to the show or edit action of an object Rails will put that objects id in the params hash and call the appropriate action in that objects controller. If you click the show link on an account it will call this action. Now the instance variable in the view show.html.erb will hold a single account instead of an array
end
def new
#account = Account.new # This initializes a new account with all the fields set to blank unless you specified a default in your migration. This account has not been save to the db yet. It is ready for a user to fill in.
respond_to do |format| # Rails can automatically respond differently to different client request. If a client i.e browser wants HTML rails responds with HTML. If a client e.g. an API want XML Rails responds with XML.
format.html # new.html.erb #
format.xml { render :xml => #account }
end
end
def edit
#account = Account.find(params[:id]) # Same as show, but mapped to a different view
end
def create # Finally we have a POST. All the prior actions were GETs, but now we are saving some data to the db.
#account = Account.new(params[:account]) # The :account key is special. It is a hash of hashes. It is populated by the form fields in new.html.erb. To access a specific field such as address we say <params[:account][:address]> and whatever the user entered in the address field in the View is at out fingers in the Controller.
respond_to do |format|
if #account.save # If the validations pass and the account gets saved redirect to the show page of the new record, otherwise refresh/render the new page (hopefully showing what error caused the record to fail to save).
format.html { redirect_to(#account, :notice => 'Account was successfully created.') }
format.xml { render :xml => #account, :status => :created, :location => #account }
else
format.html { render :action => "new" }
format.xml { render :xml => #account.errors, :status => :unprocessable_entity }
end
end
end
def update # This is another of the seven RESTful Rails actions and results in a PUT request because you are updating an existing record
#account = Account.find(params[:id])
respond_to do |format|
if #account.update_attributes(params[:account])
format.js # Rails can also respond with JavaScript. Look up UJS. Rails 3 has made large improvements here.
format.html { redirect_to(#account, :notice => 'Account was successfully updated.') }
format.xml { head :ok }
else
format.js
format.html { render :action => "edit" }
format.xml { render :xml => #account.errors, :status => :unprocessable_entity }
end
end
end
def destroy # This results in a DELETE
#account = Account.find(params[:id])
#account.destroy # destroy is a more thourough delete and will check the options of this records associations and destroy the associated objects as well if they are dependant on this object. The option <:dependant => :destroy> is not set for this object's only association: User. The user this account belongs to will therefore survive the destruction of this account.
respond_to do |format|
format.html { redirect_to(accounts_url) }
format.xml { head :ok }
end
end
end
View
Hopefully you can draw your own logic from here. The view is designed to render information passed as instance vars from a controller to a client: browser, api, smart phone. As well as to pass information from a client to the controller via the params hash. No complicated logic should get performed in a view even though a view with erb has the capability to execute any ruby code.
If an example view would also be helpful I am happy to oblige.
The best description of what the controller is:
http://edgeguides.rubyonrails.org/action_controller_overview.html
http://edgeguides.rubyonrails.org/routing.html
The controller doesn't communicate with the Database. The controller talks to the model, which then communicate with the database.
When I was starting I found very useful to use scaffolding and just looking at what was created.
Do this:
rails generate scaffold Post name:string title:string content:text
Examine all files under the app/ folder. Examine the file config/routes
Then comment here your specific questions.
At first, I thought this question was far too broad, along the lines of "how do I program?" But after reading your comments, I see what you're getting at. You don't quite grasp how MVC works in Rails and are wondering where your code goes.
What you should strive for is a Skinny Controller and a Fat Model. Keep logic out of views. So in your example, you calculate the account balance in the Model, and pass that information along (using the controller) to the view.
For a concise explanation for beginners with sample code, I recommend this article over here.
I've created a custom method in my model, which finds a record by name:
def find_city
Place.find_by_name(city_name)
end
I can call this method in my view with place_path(#place.find_city), which works great when a place with the appropriate name exists. What I would like to be able to do is write in a redirect for when the place doesn't exist, and I'm unsure about where the logic should go. Basically, I would like to write something like:
respond_to do |format|
if #place.find_city.blank?
format.html { redirect_to :action => "new" }
else
format.html { render :action => "show" }
end
end
...but I would still like the controller to respond to place_path(#place) in the usual manner as well. Any help would be much appreciated!
EDIT: sorry for the confusion, should have explained my example further. I have a Place model that has both 'city_name' and 'name' as attributes. The find_city custom method that I detailed above finds the place whose name matches the city_name for another place eg.
Place.name = "foo"
Place.city_name = "baz"
So therefore Place.find_city gives the record where Place.name = "baz". Cheers!
Do something like this
keep your model as
class City < ActiveRecord::Base
named_scope :by_name, lambda {|city|{:conditions => "name=#{city}"}}
end
in your controller
class CitiesController < ApplicationController
def index
#city = City.by_name(<city name>)
if #city.nil?
<redirect to one place>
else
<redirect to another place>
end
end
end
and in your view access the #city parameter.
** Normally we shouldnt access Models directly from views. Either we should do it through controllers or helpers
Hope this helps
cheers
sameera
I've decided to create a helper method for this problem - what I've described above might seem a bit of an unorthodox approach, but I only need the find_city method to create a links bar for each place, so I don't think I really need to create a separate city model, or define a formal self-referential relationship. Just in case anyone might find this useful, I've created a links_bar helper:
module PlacesHelper
def links_bar(place)
if place.city_name.blank?
render "no_city_links"
elsif place.find_city.nil?
render "nil_find_city_links"
else
render "complete_links"
end
end
end
Each partial then has the required behaviour depending upon whether or not the find_city method returns a record or not.
I'd like my application to display different data on the frontpage depending on whether the user has been logged in or not.
def index
if current_user
# render another controllers action
else
# render another controllers action
end
end
I can achieve this by using render_component. However it has been obsolete for some time. Although I can still use it as a plugin, I'm interested if anyone has a better approach.
Just take in mind that rendering another controller's view directly is not an option.
Thanks.
Just use your index method as a public proxy to the specific view you want to render.
def index
if user?
logged_in
else
logged_out
end
end
private
def logged_in
# stuff
render :action => "logged_in"
end
def logged_out
# stuff
render :action => "logged_out"
end
If it is a relatively small subsection of data, I'd probably do that in a view helper.
Let's say I have a User model, and an Invoice model with a belongs_to :user association.
Now I'm creating a new action for my InvoicesController, and the view that will be rendered. The view will have a select-element for selecting the user that this invoice will belong to.
So I need to fetch those users somewhere; my instinct is to leave this kind of thing out of the view. I end up with this:
def new
#users = User.all
end
The form submit action is create. When the creation fails for some reason, I re-render the new action's view.
def create
invoice = Invoice.new params[:invoice]
if invoice.save
flash[:notice] = 'Invoice created!'
redirect_to :action => 'show', :id => invoice.id
else
#users = User.all
render :action => 'new'
end
end
But as you can see, in order the re-render the new action, I have to fetch the users again.
This is just an example, but consider that I have some forms with several select-elements filled from the database, or similar constructs. That turns into an awful lot of repetition.
So how should I structure my controller in this situation?
Should I simply use User.all from my view?
Should I call new from within create to do the fetching for me?
Or something else?
For this I'd use a before_filter. For example you'd do something like:
before_filter :fetch_all_users, :only => [:new, :create]
protected
def fetch_all_users
#users = User.all
end
For 90% of my controllers I use the inherited resources plugin. It cuts down the amount of controller code you need to write for CRUD controllers, which also means you can cut down on the amount of tests you need to write.
For me:
What's the rails way to load other models collections for new, edit update and create actions?
It's not a good approach for my situation. Where after ".save", I send redirect_to to an another action, if I use before_filter and ".save" returns true, the fetch_all_users is called unnecessary