Level 5
This is personal preference, but in this case i think this might be a bit of a code smell. What do you want your CMSController to do? What methods are you using?
Nov 21, 2017
8
Level 2
Is there a controller naming convention for an acronym?
Hello,
I'm trying to build the right habits and I am creating a controller for a CMS. What is the best practice to name it?
I know generally:
Controller class names use CamelCase and have Controller as a suffix. The Controller suffix is always singular. The name of the resource is usually plural.
More specifically, what happens in atypical case scenarios?
- For example, on a word like Moose (pl is Moose), I assume it would simply be MooseController.
- For an aconym it's a little less clear to me but would it be based upon the final word of the resource? i.e. I could see a controller on Compact Disks making sense to become CDsController. For a CMS however, I'm not really controlling multiple CMSs but rather the contents of one. I feel like CMSController makes more sense.
Is there a ruleset somewhere on this? Sorry if this is a bit pedantic, I know ultimately it doesn't make a difference and already went with CMSController.
Thanks!
Level 67
CMSController seems overly broad. Is this controller going to have all methods for the cms? Probably not, or it'd be a huge controller. Break it up into individual responsibilities. ArticleController, PublishController, WidgetController, MediaController, etc.
1 like
Level 2
Hmm, great points and I think maybe a clearer way to name the mentioned controller would be using ListingsController. I'm converting over a old website where the "CMS" is being used to refer to the site's main content. In this case more specifically attractions and/or business listings. From a quick look at the DB there will probably also be an EventsController, RoomsController, HotelsController, ++
Generally speaking though it sounds like it would be up to my preference on the naming?
I noticed already @cronix you seem to prefer using singular in the resource name? It's a tad confusing, from https://laracasts.com/series/laravel-from-scratch-2017 Jeffrey suggests plural resources for Controllers, singular for Models, etc. From a quick google RoR docs seem to suggest also the same.
I guess it really doesn't matter assuming the ultimate code is logical and readable?
Level 5
yeah and plus you can always refactor down the road once you get a hang of things. There really is no "wrong" way to do things ... for the most part haha
What i would suggest though is to give Adam Wathan's talk a watch, really good overview on how to do controllers IMO https://streamacon.com/video/laracon-us-2017/day-1-adam-wathan Keeps things clean and easy to manage down the road
Level 80
@taf I’m in the singular controller names camp, so I’ll have things like ArticleController, EventController etc. My reasoning being—with the exception of the index() method—the other resource methods (create(), edit() etc) act on a single entity, so my ArticleController is controlling an article.
As for the issue of acronyms, I’ll still camelCase them. If you look at a new Laravel installation, you’ll see the Http folder is camelCased instead of being HTTP. It’s because if you were to then try to automatically snake_case that namespace or class name, you’d then get h_t_t_p or c_m_s_controller, which isn’t the intention.
Other than that, I echo other people’s thoughts: a “CMS controller” is definitely overly broad :)
1 like
Level 67
Plural/Singular controllers are really up to you. I name mine singular, mostly for the reason @martinbean spells out. There is nothing automatic in laravel that assumes it for controllers (since you have to manually link endpoints to controllers via the routes), unlike when it comes to naming Models and DB Tables where part of Laravels magic assumes plural Table names and singular Model names so it can automatically link a model with a table (you can override this by specifying the table name in the model).
I also highly suggest watching Adams Laracon talk linked above when it comes to breaking up controllers into responsibilities. If a controllers methods grow beyond the basic REST verbs, time to make an additional controller.
Level 2
Thanks a bunch. This was very helpful and I really like the approach suggested in Adam's talk. In particular as mentioned trying to keep controllers limited to CRUD/REST actions. I think it's a way to keep things simpler for me and follows the sentiment of another suggestion I was given to take advantage of what's built into the framework.
I'm sure it's going to take some experience (and refactoring :P) but it feels like a good starting base. I can see already why CmsController would be way too broad and even my mentioned ListingsController should probably be broken down.
Good to know also on the plural/singular distinction and I guess I'll defer my preference until later and just stick with the way I learned for now.
On the Acronyms @martinbean was right also. I already ran into some problems with "CMS" when I carried it through to creating the model (CMS.php). I had to rename it to Cms.php or I got an error due to I guess some built Laravel automatic interactions between the Model and Table.
Base table or view not found: 1146 Table 'somedatabase.c_m_s_s' doesn't exist
If I come across the situation again to stay consistent I'll use AcronymController & Acronym.php.
I marked @JeffBeltran answer as best so others will find the very helpful link.
Level 7
Name the controllers based on intent. So either single or plural. Eg.
UserController vs UsersController
Are not the same. The first can be a controller for managing a user account, profile. While the second is for batch handling users, for example.
Acronyms you want to capital/camel case. ApiController, SmsController, it seems odd but with experience you realize it just works, reads better. By same token, and this is where it becomes obvious, you wouldn’t capitalize a namespace segment
Api\SmsController and not API\SMSController
Please or to participate in this conversation.