Zend Framework: Controller class == Page?

Question

Am I right in thinking that in Zend Framework, if I plan to have 5 pages at my site, I'd generally need 5 controllers? Do ZF developers typically create 1 controller per page ("page" as abtract app unit)?

The reason I am asking this is that previously for some reason I stuffed a lot of various actions into controllers so that they played role of pages, e.g. index/add, index/view, index/delete and displayed various small screens, e.g. small CRUD screens as opposed to grids displayed by index action.

But as of now I want to check my new understanding that actions are needed mostly for model updates and actions should, once run, immediately redirect back to controller/index. So it seems that views should mostly be used in index actions, and less frequently in other actions.

Does this sound architecturally valid?

Answer 1

indexAction is merely the default action for a given controller, useful for displaying a default view (the same as displaying the index.html or index.php page for a sub-directory).

It is completely acceptable to create a variety of actions on a per controller basis that may or may not each have their own views (i.e. add and edit). The controller is intended to group similar actions.

For example usage please refer to the documentation on Zend_Controller_Action. You may also find it useful to familiarize yourself with the workflow of Zend_Controller.

Answer 2

In my opinion, a controller should always group multiple methods that have a common use case. Try to find "nouns", that describe the functionality of your app: those are the controllers (while verbs are the controller methods).

If you have (for example) a blog, you may have:

• ArticleListController (listing all articles, listing the top 10, listing all articles for a tag,...)
• SingleArticleController (displaying one article, adding comments,...)
• AdminController (lets you write Articles)

If you have just 5 pages (e.g. home, about, contact,...) the MVC architecture might not be the right fit.

Answer 3

I suppose thats one way of doing it... Using your analogy i suppose i use a controller like a "section" and actions like "pages" to those sections.

But thats getting stuck more on the old procedural||static paradigm of pages because really the action controller itself has no more to do with a page or section than the association you make as a developer. Ie. each page can potentially be a composite of numerous actions and views depening on the application's architecture.

For example if i have a blog modules i might have the following:

Controllers:

• PostController
• CommentController

Views:

• post
  • display (display a single post)
  • list (list posts)
  • edit (create/edit post)
• comment
  • display (display n comments)
  • list (list comments)
  • edit (create/edit/moderate comment)
  • embed-list (for use on the Post itself assuming this differs from display)