Naming Conventions

Naming Conventions

This should be treated as a proposal on our naming conventions for certain resources. Although it is not must have it might be a best practice in most cases.

Table of Contents

1. General
2. Routes
3. Permissions
4. Language resources
5. Service Container

General

The general idea behind the convention is to name resources from the most general fact to the detailed object we actually try to access. For more details see each resource listed in this article.

As a separator of multiple keywords a single dot . should be used, as it is the way laravel internals treat string keys for resources by default. It simply fits into the whole framework better.

If a namespace is used (in most cases only for views and translation) it is separated with a double colon ::, also defaulting to the laravel framework.

Examples

• user.profile.show (as a route to the user profile)
• site::admin.title.create (as a translation for the title of the create page in the site module)
• blog::post (as a view for a specific post in the blog module)

Routes

Routes should be named in the following scheme: module.section.resource.action with the following meaning:

• module: the module which provides the route
• section: whenever the route targets the backend this should be admin and can be left otherwise
• resource: the resource which is addressed with this route
• action: basic rest operation which will be executed on the given resource

NOTE: Though some modules have only one resources the routes are redundant in some cases. (i.e. user.admin.users.index) but if the same structure is used throughout the whole project it is much simpler to write routes out of a habit. Otherwise you may have to check a route everytime you try to link something.

This also makes it necessary to configure route names if you use Route::resource(), you can do it like this:

Route::resource('sites', 'SiteController', ['names' => [
        'index' => 'site.admin.sites.index',
        'create' => 'site.admin.sites.create',
        'store' => 'site.admin.sites.store',
        'show' => 'site.admin.sites.show',
        'edit' => 'site.admin.sites.edit',
        'update' => 'site.admin.sites.update',
        'destroy' => 'site.admin.sites.destroy',
    ]]);

Permissions

Permissions should be named in the following scheme: module.resource.action with the following meaning:

• module: the module which provides the permission
• resource: the resource which is addressed with this permission
• action: basic rest operation which shall be executed on the given resource

It would be pretty straightforward if the action is named after the conventions from Route::resource() (i.e. show, create, edit, destroy).

NOTE: Same as for routes we can say:

Though some modules have only one resources the routes are redundant in some cases. (i.e. user.users.update) but if the same structure is used throughout the whole project it is much simpler to write routes out of a habit.

Language resources

For languages it is not possible to figure out a general pattern but here are some expectations which your language keys should meet:

• grouping keys as much as possible (reduces the variety of new keys)
• name the path to the lang file somewhat like the resource
• make it easy to follow and understand the meaning

Service Container

Service Container accessors should be named in the following scheme: service.other.relevant.keys with the following meaning:

• service: the service which you are trying to access
• other.relevant.keys: not necessary sometimes but should be named after the service to make it feel grouped up a little, see examples

Examples

• menu.frontend (we want to access the menu handler for the frontend menu)
• menu.backend (we want to access the menu handler for the backend menu)