I tend to look at it this way:
Determine processing requirements.
What does each "action" need? An edit action and a delete action probably require an :id param. An add action and a list action probably do not. These controllers/actions then consume the params and do the processing.
Note: You can write these comtrollers/actions without any reference to the urls that bring visitors there. The actions simply expect that their params will be delivered to them.
Decide (!) what url's you want.
In general, I find the the
(/:module/):controller/:actionpart of the url largely works fine (except for top-level relatively-static pages like/about, where I often put the actions on an IndexController (or a StaticController) and resent having to include the/indexprefix in the url.So, to handle posts, you might want urls like:
/post- list all posts, probably with some paging/post/:id- display a specific post/post/:id/edit- edit a specific post/post/:id/delete- delete a specific post/post/add- add a post
Alternatively, you might want:
/post/list- list all posts, probably with some paging/post/display/:id- display a specific post/post/edit/:id- edit a specific post/post/delete/:id- delete a specific post/post/add- add a post
Or any other url scheme. The point is, you decide the url's you want to expose.
Create routes...
...that map those routesurls to controllers/actions. [And make sure that whenever you render them, you use the
url()view-helper with the route-name, so that a routing change requires no changes to your downstream code in your actions or views.
Do you end up writing more routes this way? Yeah, I find that I do. But, for me, the benefit is that I get to decide on my urls. I'm not stuck with the Zend defaults.
But, as with most things, YMMV.