(resend - sorry!) Which controllers?


#1

Hello,

I have recently started learning RoR. I think it’s fantastic. I am
absolutely blown away.
OK, this is to prepare you to my idiotic question. Hopefully, I won’t
be stoned.

I am designing a simple application, where users can register, and:

  • Publish a photo album
  • Publish a simple blog with comments
  • Determine their list of friends and foes

The application will obviously have a front end and a backend.
The front end will give people a chance to search, and “find” members
and blogs
The back end will allow people to manage their profiles and add blog
entries.

Now: I like the idea of urls like this:

domain.com/user/merc/blog

Where:

  • “user” is the controller
  • “merc” is the user id
  • “blog” is the action (in this case, show the blog)

The backend could be:

domain.com/backend/merc/blog

Where everything is as above, a part from the fact that “backend” is
the controller.

This does mean that each controller will have quite a few actions.

I guess my question is: how do you decide what a “controller” is and
does? How should I divide the application amongst several controllers?

Well… I hope I didn’t embarrass myself too much.

Thanks a lot and bye!

Merc.


#2

Hey Tony !

You should get the Agile Rails Book, and read it too :slight_smile:
Creating a logical controller structure if pretty darn easy… for
instance,
some of my controllers are:
admin_controller.rb, animal_controller.rb, blog_controller.rb

It all makes sense when you read the book, and most importantly, start
getting your hands dirty creating your application !

Have fun too !

Dylan


#3

Tony M. wrote:

Hello,

I have recently started learning RoR. I think it’s fantastic. I am
absolutely blown away.
OK, this is to prepare you to my idiotic question. Hopefully, I won’t
be stoned.

I am designing a simple application, where users can register, and:

  • Publish a photo album
  • Publish a simple blog with comments
  • Determine their list of friends and foes

The application will obviously have a front end and a backend.
The front end will give people a chance to search, and “find” members
and blogs
The back end will allow people to manage their profiles and add blog
entries.

Now: I like the idea of urls like this:

domain.com/user/merc/blog

Where:

  • “user” is the controller
  • “merc” is the user id
  • “blog” is the action (in this case, show the blog)

The backend could be:

domain.com/backend/merc/blog

Where everything is as above, a part from the fact that “backend” is
the controller.

This does mean that each controller will have quite a few actions.

I guess my question is: how do you decide what a “controller” is and
does? How should I divide the application amongst several controllers?

Well… I hope I didn’t embarrass myself too much.

Thanks a lot and bye!

Merc.

The functionality you need can be found in config/routes.rb. I’m
abolutely no Rails expert, and I have no idea if the following will
work, but try it out anyways:

map.connect “backend/:name/blog”,
:controller => “backend”,
:action => “blog”

or maybe you could just do something like

map.connect “:controller/:id/:action”

Hope this helped and sorry if it screwed anything up,
–Evan


#4

Often (not always), your controllers are in sync with your table
names. If you have a “users” table, you’ll have a user_controller.rb

A URL such as /user/edit/13 would invoke the “edit” function under
user_controller.rb, and would typically be used to edit the entry in
the users table with id=13. The “edit” function may look like:
class UserController

def edit
@user = User.find(params[:id])
end

You would then have an edit.rhtml, which would be rendered by default
when the edit function exits (note that the edit function renders
edit.rhtml by default; it can be changed, but I try not to change it
unless I have to for the sake of simplicity). It may contain stuff
like

...

User name: <%= @user.name %>

User email: <%= @user.email %>

where @user has been populated by the edit function in
user_controller.rb

That’s basically how the MVC stuff works; you can override it, extend
it, tweak it to your heart’s content, but that’s essentially.

As to when you need to define a “new” controller, as I said it often
makes sense to start from a premise of one per table as the “default”
and go forward from there. This is particularly the case where the
users interact more or less directly with tables (e.g. user creates an
order; it goes directly into the “orders” table), but may be less
applicable where user activities are less directly linked to specific
tables. Some tables don’t need to be explicitly populated by users
doing stuff, or may be populated as a result of users changing data in
other tables - in this case, it may not make sense to create
controllers for these tables. Alternately, you might e.g. define a
controller named “reports” (even when you don’t have a table named
“reports”), and drive all the report generation stuff for your entire
application through the “reports” controller. You might want a
controller named “login”, and route all By and large, most apps will
break down into logical chunks of functionality (e.g. login,
reporting, data entry/maintenance on a per-table basis, etc.) and
these would tend to be mirrored one “chunk” per controller.

I realise that’s a bit vague; does anyone else want to take a shot at
it?

Regards

Dave M.


#5

Hi,

First of all: thanks a lot for your answer!

You should get the Agile Rails Book, and read it too :slight_smile:

Wooops… I am up to page 100 with that one!
(And I still don’t get it. Shame on me!)

Creating a logical controller structure if pretty darn easy… for
instance, some of my controllers are:
admin_controller.rb, animal_controller.rb, blog_controller.rb

OK!
My “problem” is that I don’t get when it makes sense logically to
create a controller.
Is it meant to control the contents of a specific table?
For example, if I create the controller “user”, I would like these
URLs to work:

/user/merc/blog/ (controller is “user”, ID is “merc”, action is “blog”
/user/merc/gallery
/user/merc/friends_and_foes
/user/merc/leave_message

This is for the front-end. Does creating such a controller make
sense? This controller wouldn’t manage a specific table. It would
fetch data from several tables, for the user.

As far as the back-end, shall I have one controller per
functionality? Or one controller to manage lock, stock and barrel?
For example, do I want to create a controller “backend”, which does:

/backend/blogs <— Show the blog entries. Action:
/backend/blog_entry_add <— Add a blog entry
[…]
/backend/images_list <---- Show the list of images
/backend/image_upload <---- Allow the upload of an image

Or shall I create several controllers?
Like this:

/blog/merc/list (controller “blog”, ID “merc”, action “list”)
/blog/merc/add
/blog/merc/delete
/blog/merc/edit
[…]
/images/merc/list (controller “images”, ID “merc”, action “list”
/images/merc/add
/images/merc/delete
/images/merc/edit
[…]

Then, I can use the route mechanism to reroute things so that I can do:

/backend/blog/merc/add (controller “blog”, ID “merc”, action “add”)

So that I keep the URLs clean.

Would this make sense?

What’s the philosophy of what controllers should be there? What is a
controller from a “logical” point of view? Shall I think of a
controller as a module that deals with one specific table?

Thanks a million and bye!

Merc