What Defines the Traditional "Page" Concept in MVC?

Question

I currently use CodeIgniter as my framework of choice when using PHP. One of the things I am wrestling with is the idea of a "page", and how to represent that properly within MVC. To my knowledge, CodeIgniter has a front controller that delegates to page controllers. In my thought process, each page would have it's own controller. All too often though I see someone using a page controller stuffed with many methods. So in that sense, each action becomes it's own page.

I've never really liked the idea of stuffing many methods into one controller, because it seems like there will be too much overhead if you only need one method or two in the controller at a time. It's seems more reasonable for each page to have it's own controller, and the actions would only correspond to something you can do on that particular page. Am I thinking about this the wrong way?

What makes it more confusing is I'll notice in some web applications where they will have one controller that will have multiple methods (i.e. login, register, view, edit, etc.), but then on others they actually have a login controller, and a register controller. What is the proper use of a "page controller"?

Answer 1

From a domain perspective I definitely say it makes more sense to have 1 controller per domain context. Not necessarily one per page although depending on the context this may be the case. What I mean by context is "actions that are closely related".

For instance an account controller should handle the login, register, logout, change password, actions. They all live within the context of an "Account"

Take Stackoverflow for example. I would have a "Questions" controller which would have actions like DisplayQuestion, AskQuestion, Delete Question, MostRecent Questions, etc. They are all different "Views/pages" that are managed by one controller.