how many controllers?

[Skyblaze]

I'm starting a new web app (my first) in rails and i have to manage at least two entities with crud operations. I wonder if one controller for the admin part (called "admin") and one for normal users/customers (called "users") is just enough. So i will have for example urls like these for the admin part:
http://www.mydomain.com/admin/new_author;
http://www.mydomain.com/admin/edit_author;
http://www.mydomain.com/admin/list_authors;
etc. and then....
http://www.mydomain.com/admin/new_other_entity;
http://www.mydomain.com/admin/edit_other_entity;
http://www.mydomain.com/admin/list_other_entity;
...and so on.

Is it right or maybe it is better to split it?

[vgarcia]

I'm starting a new web app (my first) in rails and i have to manage at least two entities with crud operations. I wonder if one controller for the admin part (called "admin") and one for normal users/customers (called "users") is just enough. So i will have for example urls like these for the admin part:
http://www.mydomain.com/admin/new_author;
http://www.mydomain.com/admin/edit_author;
http://www.mydomain.com/admin/list_authors;
etc. and then....
http://www.mydomain.com/admin/new_other_entity;
http://www.mydomain.com/admin/edit_other_entity;
http://www.mydomain.com/admin/list_other_entity;
...and so on.

Is it right or maybe it is better to split it?

Split it. A single controller shouldn't manage multiple entities like that, it's typically bad design. If anything, I'd use the same controllers as the public side and use before_filters to hide any restricted actions (i.e. deleting an author) from public view.

[Skyblaze]

Split it. A single controller shouldn't manage multiple entities like that, it's typically bad design. If anything, I'd use the same controllers as the public side and use before_filters to hide any restricted actions (i.e. deleting an author) from public view.

so you'are saying that in general i have to create a controller for every entity i have to manage and instead of using "admin" and "customers" controllers i only use entities controllers and protect any actions for admin users right? And for other actions/template not directly connected to those entities i must create another more generic controller?

[Skyblaze]

...and if the application is in a website so intermixed with static pages how can i organize those staic pages? empty actions (so only rendered .rhtml static templates) in yet another controller like "main_controller.rb" or "site_controller.rb"?

[vgarcia]

so you'are saying that in general i have to create a controller for every entity i have to manage and instead of using "admin" and "customers" controllers i only use entities controllers and protect any actions for admin users right?

Yeah basically. Here's a quick example: let's say you have two models - User and Post. Posts belong to users and Users have many posts. You want users who aren't logged in to be able to view posts, but not edit/create/destroy them. Here's what the Post controller would look like:

class PostsController < ApplicationController
  before_filter :login_required, :except => [:index, :show]

  def index
     ....
  end

  #other actions
end

Anyone who tries to create a new post will have to log in first. If you wanted to, you could even show a different layout based on which action is being displayed, so you can have an admin layout and a regular user layout in the same controller:

class PostsController < ApplicationController
  before_filter :login_required, :except => [:index, :show]
  layout :user_layout

  def index
     ....
  end

  #other actions

  private
  def user_layout
    (&#37;w(index show).include? self.action_name) ? 'main' : 'admin'
  end
end

And for other actions/template not directly connected to those entities i must create another more generic controller?

I'm not sure what you mean by this. Care to expand a little?

[Skyblaze]

I'm not sure what you mean by this. Care to expand a little?

I mean to manage static .rhtml pages.....in essence static pages of the website.

[vgarcia]

I mean to manage static .rhtml pages.....in essence static pages of the website.

If the static pages make sense in the context of the controller, then yeah an empty action is fine and just add the content in a .rhtml file. But if your application is about managing static content, then perhaps you should do a Page model/controller to manage the content and use routes.rb to make prettier URLs for each page.

[Skyblaze]

If the static pages make sense in the context of the controller, then yeah an empty action is fine and just add the content in a .rhtml file. But if your application is about managing static content, then perhaps you should do a Page model/controller to manage the content and use routes.rb to make prettier URLs for each page.

ok with that information i wonder if it is wise to use rails to build a normal static website to use rails facilities and comodity like for example the template engine...or managing static content in a model in a database etc.

[Skyblaze]

If the static pages make sense in the context of the controller, then yeah an empty action is fine and just add the content in a .rhtml file. But if your application is about managing static content, then perhaps you should do a Page model/controller to manage the content and use routes.rb to make prettier URLs for each page.

how could i use routes.rb in that sense? If i create a Page controller (with or without the support of a Page model also) i can already do pretty url by create empty action in Page controller with descriptive names.

[vgarcia]

how could i use routes.rb in that sense? If i create a Page controller (with or without the support of a Page model also) i can already do pretty url by create empty action in Page controller with descriptive names.

routes.rb:

map.connect 'pages/:pretty_name', :controller => 'pages', :action => 'show'

/app/controllers/pages_controller.rb

class PagesController < ApplicationController
  def show
    @page = Page.find_by_pretty_name(params[:pretty_name])
  end
end

In this case "pretty_name" would be a field in your 'pages' database table with a URL-friendly permalink (like what wordpress does, i.e. 'about-me'). But this is only useful if you're going to have a lot of static content. I wouldn't bother if you only have like 3 or 4 static pages for example.

[Skyblaze]

routes.rb:

map.connect 'pages/:pretty_name', :controller => 'pages', :action => 'show'

/app/controllers/pages_controller.rb

class PagesController < ApplicationController
  def show
    @page = Page.find_by_pretty_name(params[:pretty_name])
  end
end

In this case "pretty_name" would be a field in your 'pages' database table with a URL-friendly permalink (like what wordpress does, i.e. 'about-me'). But this is only useful if you're going to have a lot of static content. I wouldn't bother if you only have like 3 or 4 static pages for example.

that is great! I will try it for sure for my next static website thanks. Anyway in the database i will put each Page entry/row with the permalink field (like you said) and a text field that contains the html for the content of the actual page right? If in the future my client asks for an english (i'm italian) part of the site i can use this method also? Eventually i will add another text field for the english html content and i will put in a session variable a flag that tells me if the user wants the english site or the italian version

[MiiJaySung]

have a look at the REST stuff in Rails 1.2. It encourages you to stick to certain actions (namely .... index, show, new, create, update, edit, destroy) in a controller and if you need more, it's a general sign that you need to divide up the site into more controllers. having many controllers is not a bad things, and controllers should be small and nimble. Liek suggested, using separate controllers for separate entities / models is highly encouraged... If there is a lot of shared code, cosider using helpers, or extending from a base set of "abstract" controllers. Partial templates also are good for refactoring views.

Avoid using namespaces for controllers (i.e. subfolders like admin, where you do class Admin::SomethingController). If you need to make sub foldersm avoid namespaces and modify the load_paths config setting (config/environment.rb) instead.

[Magic8Ball]

So to Summarise:

You should not have more than one controller per model
you can link controllers methods by using the Filter options ie filter_before, filter_ after etc

and you can use the routes.rb file to create prettier URL's or hide the names of the controllers from the URL's

correct ?

[vgarcia]

You should not have more than one controller per model

Not true; actually the reverse is more true. Make as many controllers as you want, but mixing up scopes (i.e. editing multiple types of models in the same controller) is what you should look out for.

you can link controllers methods by using the Filter options ie filter_before, filter_ after etc

Not really linking, just controlling access/layouts/etc.

and you can use the routes.rb file to create prettier URL's or hide the names of the controllers from the URL's

correct ?

Yep

[Skyblaze]

I would like to reopen this thread to issue a problem when we dicide to use rails to manage a static only pages website. I like the idea to use rails to a static only site and i would like to try the method explained above of putting the html and content in a database and create a model/controller to manage all with the help of routes.rb and clean urls permanently stored in a field in the database. In that manner we can manage better the static content and use all the rails facilities and at any time we can upgrade the site with a foreign version of the same site (we have only to add another field in the table with the foreign content/html).
Said that anyway i wonder how can i put all the html/content in the related table field? I'm talking about puttting also the rails layout html/content in the database so if i have to make a foreign version of the site i can "load" the layout with the appropriate language/html/content also for the site's layout.

[Skyblaze]

up