All controllers in Laravel 5 are still named with Controller suffix, like AuthController and PasswordController. Is there any reason to follow this convention with own controllers, or are those suffixes just leftovers from pre-namespacing era?
I use action-based URL generation most of the time, so I avoid linking like url('home'), but prefer something like action('HomeController#index) instead. This way I can change URL patterns without a headache.
But action('Home#index') is so much more elegant. Any traps behind it?
There's no need to add the Controller suffix. If it was really needed, when you create a Controller through artisan, it would automatically add it, or complain about it, and it is not. So, feel free (but keep in mind that if you want a controller "Dog" and there is a model "Dog"... well, it will be complicated).
No need of adding Controller Suffix. It is just user recognition. So that we can easily get that is an controller. You can normally create Home instead of HomeController. And action('Home#index') will perfectly work. But models in Laravel is something different. If your model name is in singular your table name will be plural. And this is also not a compulsory thing. But if we add Controller in suffix it would be best in using controller and model. Because we will add use home and use app\home in the controller. This would confuse us.
Having Controller at the end of every controller class name does feel like a type of Hungarian notation. However, a class's name should tell the programmer quickly and unambiguously what it does. A DogController is not a Dog. In fact, I can't think of a better name than DogController for it.
Yes, it is namespaced as App\Http\Controllers\DogController which seems like double handling, but how often do you think about or refer to a class by its fully qualified name? Most often a class is referred to just by its class name, and PHP even allows you to do this in code with use App\Http\Controllers\DogController; which will make DogController a valid class name in your code.
That being said, Laravel will not force you to use this convention. If you are working with other programmers you need to have an agreed naming convention, and using Laravel's is the easiest as well as the one most Laravel programmers will already be familiar with.
Related
As far as I know, currently Yii 2 doesn't have an out of the box method to resolve ambiguity of controller and module names. An example of module hierarchy to describe what exactly I mean:
app\modules\v1\controllers\UserController // resolves the /v1/users and /v1/users/{id} actions
app\modules\v1\modules\user\Module.php // nested module, resolves the /v1/user/... controllers and their actions, e.g. /v1/user/something/{id}
In this case, the UserController conflicts with the user Module. The main reason of the ambiguity is the singular-plural magic of Yii 2 framework. I didn't find an appropriate solution to resolve this ambiguity. Further my ideas how to resolve it.
Rename the module.
Rename the UserController to the UsersController.
Create an additional submodule, and place there the UserController. E.g. app\modules\v1\modules\root\controllers\UserController
I'm not sure that at least one of these options is a quite elegant one and a proper solution in view of the Yii 2 philosophy.
Coming back to the main question, what is a more appropriate approach to resolve this issue by the Yii 2 philosophy? Controller and Module is two different types of objects, which is differently pluralized or not, thus should be right way to separate them in the routing for the described case.
How I usually deal with this depends a bit on how I'm structuring things.
Let's say I have users, departments, orders and maybe some other stuff. All these concepts have their own module in which all interactions take place. If I want to create REST controllers for all these concepts I can choose to add a controller to every module or I can create a dedicated API module for the controllers.
When creating a dedicated module for this purpose I usually name it api, maybe with some nested versioning module(s) inside. So in this situation I would get the following structure app\modules\api\controllers\UserController which would result in the URL /api/user. No ambiguity there and pretty clear what this is meant for.
When adding such a controller to the module itself I choose a better name than just 'UserController'. When asking myself the question 'What does this controller accomplish?/What does it do?' I find that just UserController doesn't cut it; Especially when inside a User module, resulting in /user/user. This controller is probably going to exist alongside one or more different controllers in the User module, all meant for something different. So, usually, I end up naming it just ApiController, resulting in /user/api. Another controller could be the ProfileController. So when looking at the URLs it's pretty clear what /user/api and /user/profile do. Without the ambiguity.
I am not sure I can fully understand the question, but probably you're asking about classname aliases?
use My\Full\Classname as Another;
I often use Ctrl+Click on a method to navigate to its declaration, or RClick -> Find Usages to see all usages of it.
In Laravel you often define in strings which method shall be called. For instance:
Route::get('customer/{id}', 'CustomerController#customer');
I see no way to navigate to the method customer in the class CustomerController automatically here. Find Usages doesn't find this one either.
Is there any way to get it working?
As you said in your question, CustomController#customer is a string. So you cannot click on this string to find out its usages.
However, you can still create a route name for your routes and check for those routes. You can use this route names in your controllers, views and even models.
So using route names would give you tremendous flexibility in development. Just change your method usage in routes.php and it will be reflected in all places.
If you're like me, you think CodeIgniter is pretty nice. You also probably hate typing _model every time you load or call a method or property from your models, because it's ugly and time-consuming.
I've been searching for a solution to this for a couple hours with no luck - so I put together a quick fix.
Take a look at the loader class documentation.
Say you've got a class called page_model, you would typically load and use it like this:
$this->load->model('page_model');
$this->page_model->function();`
If you want to avoid typing _model every time you can do this:
$this->load->model('page_model', 'page');
$this->page->function();
When I first started using CodeIgniter I always did this. Now after using CI for several years and a number of websites, I regret that decision.
It's harder to tell what's going on when looking at the code. Having the _model as part of the code that calls the model function removes any ambiguity. For example, in the above function call is page a library or a model?
This is because CodeIgniter does not support namespaces. While there have been discussions of namespace support in CI for some time, support in the stock codebase is still forthcoming.
The solution? Prefix your controllers instead! In typical usage, you're unlikely to need to type the name of the controller more than once per file.
First edit application/config/routes and add the following line after all the other routes:
$route['(:any)'] = "c_$1";
With this rule, you route the first segment of the URI to the matching controller with your prefix. So that:
http://www.domain.com/fishsticks
maps to the following controller:
c_fishsticks
Next, rename your controller files with this prefix, as well as altering the class names inside to match.
That's it! Now you can name your models with relative freedom. You can rename your models at your leisure, but don't forget that you need to change each model's filename, each model's class name, as well as all references to each model. This is easily the most time-consuming step, but on the plus side you don't have to do it all at once.
I am starting a new project and want things to be done right:
Controller:
file name: routemanagerdashboard.php
class name: RouteManagerDashboard
Views:
file name: routemanagerdashboard_dashboard.php
Model:
file name: routemanagerdashboard_model
These naming conventions are perfectly fine. Although there are some conventions you must follow, what you name your files/classes mostly comes down to personal preference. After working with CodeIgniter for a couple years I've settled on the following naming conventions for my files.
Controllers: companies.php (plural file and class name)
Models: company_model.php (singular of the table it corresponds to)
Views: companies/method_name.php (all views for the controller go into a folder for views in that class)
I always make my database table names plural and have a one-to-one relationship between my models and tables. Controllers usually have a corresponding table and model, but not always. I also use a base model which removes a lot of the tedium of setting up a new model for every table which fits into this setup very well and is probably a big reason that I stick pretty strictly to it.
This is fine, but routemanagerdashboard seems a bit verbose, you may consider coming up with something shorter. If you like the controller class name but hate the long urls, you can always use a route to get around it.
Since we're dealing with PHP, case sensitivity is not an issue, so your controller class name is fine, just as long as it matches the characters in it's file name. Just stick to lowercase file names.
Your model name is using the common CI convention, but be aware that when loading the model you may use the second parameter to alias the class name for easier use. Example:
$this->load->model('routemanagerdashboard_model', 'r_model');
$this->r_model->get_something(); // A little easier to work with
On views: It's probably better to create a subdirectory for all views that are directly related to the controller. You are probably going to need more than just one view file per controller. You will see your /views folder become unmaintainable if you put all view files directly in the root of it. I suggest you use sub directories and short meaningful file names, perhaps matching the name of the controller method you intend to load them in. Example:
// file = /views/routemanager/dashboard.php
$this->load->view('routemanager/dashboard');
So, yes - you're Doing it Right for the most part, but coming up with shorter names if possible, and organizing your view files into subdirectories will probably be a good idea.
Ok, it's my fault. I've never ever learned programming at a school and that's why i'm always ending up in a spaghetti code. I've always curious about different patterns and tried to understand them at least in a basic level.
MVC is my worst fear and i think i'll be never able to use it's advantages because of i don't understand it's fundamentals.
My actual question/problem looks like:
The front controller calls a 'Core' class which is doing some initialization then it calls the actual controller with the correct action/parameters. The controllers always extending the 'Core' class so i can acces it's variables, etc. They're working nicely together but here comes my real problem.
Some kind of methods (getting a database entry in most of the cases) are required in different cases. (e.g. a product needs it's manufacturer)
In this scenario i have two (bad) choices:
Inject the required method into the 'Core' class so it's getting bloated over time
Inject the required method into the actually called controller so i will end up a redundant codebase
I see a lot of possible problems in my approach:
Controllers are always extending 'Core' class
'Core' controller holds the database object so without it i cannot access my Db
Database functions (e.g. getting a product) are in the controllers but i cannot access them because they're always calling 'Core' first (extending problem again)
Please tell me:
Where is the biggest problem in my approach and where can i correct it?
Note:
Please don't treat this as a general question, i think this is an answerable thing. If you need some clarification, please ask for it and i'll try to lighten up things.
Thanks for your precious time, fabrik
Your data is represented to your Controller and View through the Model. The Model may be supported by a Repository but depending on the overhead you might want to provide your database access in your Model. The data architecture should be similar to this:
(Repository<===>)Model<===>Controller--->View
Your biggest problem is having the "Core" class, get rid of it asap.
By the way, the FrontController is not the only way to do things MVC things either.
Your second problem is that controller deals with database, it shouldn't. I suggest you use some abstract data layer, which you use only in your models. And controller should deal only with models, it shouldn't care how models get their data persisted and fetched.
Look into using a DI framework to automatically inject an instance of a repository into your controllers (or even better, a proxy class). Try to keep business logic outside of your controllers, but rather, refector it out into a helper or proxy class.
I tend to split my logic up into views => controllers (just for interaction between business later and view) => business logic => models (DTOs) => low-level data access at a minimum.
Also, if you need common helper functionality in your views, perhaps create several extensions to help.