I'm new to OOPHP and frameworks at all.
I'm just wondering...
I have few controllers:
dashboard
signup
login and few more
I've put them into users directory. Everything is working correctly, I'm just wondering if I should put everything in one controller and signup, etc. should be a method of users controller? Or am I doing it correct way?
Regards,
M
It's totally up to you. The stuff you currently have could probably all go into one controller (user controller in this case), but it can build up to request the separation you already have, e.g. separate controller for each action, grouped by a prefix.
Good thing about kohana is that it allows you to do stuff like this the way you want to, there isn't a single guideline about putting many 'common' actions into the same controller; do it as you like / find appropriate.
Related
I want to build a Laravel application which users both web and API parts. The common (and mine as well) question is whether to use separate controllers or not.
There are 2 options:
Separate controllers
Laravel API controller structure?
Use one controller and check the request type (is Ajax, or depending on the request link) and return either JSON or HTML.
Laravel resource controllers for both API and non-API use
Those who have the 1-st opinion doesn't explain the DRY problem solution - web and API controllers would be the same except the return statement (JSON or HTML view). But since most post recommend to separate controllers I suspect I don't understand something about the DRY problem solution.
I don't see any disadvantage of the second method. But people say something like
If you use only one controller, you will end up soon with a messy class with thousands of lines. Not only this is not going to scale well, but it will be hard to work with for you and your teammates.
Please explain me the DRY problem solution for the first approach (separate controllers) and the possible underwater rocks in the second approach (single controller)
Please explain which approach is preferable.
I think this is a great question, and I too am keen to see the responses.
I can see the arguments for both approaches. I however would create and maintain separate controllers, whilst using services to share common logic between the controllers where it is known that this will never change.
For example, if you allow users to upload avatar images. I would put such logic in a service and consume this service in both controllers.
The reason for this approach in my mind, is that the web and API logic may diverge and it would therefore be easier to iterate each without impacting the other.
If this is unlikely, then I would still create separate routes, but point them both at the same controllers, so that if it did change in the future, you can simply re-point the API routes to their own controllers.
Where should the authorization code in Laravel? We have a lot of options and a lot of plugins to manage this situation but and I'm not really sure where I should put all logic. Let's see:
I know that there are a lot of possibilities with a correct result but I want to know which is the optimal solution for you or know your techniques in this situations.
Imagine we have a help desk application done in vuejs and Laravel as API, so we have users, groups, roles, permissions. And maybe a user will only able to see its tickets.
Should we do a TicketPolicy with view, update, create methods? Maybe should we use repositories? Maybe a is_user_allowed method in Ticket's model?
Should we use middleware in routes files and do something like Route::get('tickets/{ticket}', 'TicketsController#show')->middleware('can:show')? Or should we call $this->authorize($ticket) in show, edit, update and store methods of the controller?
Or maybe should we use FormRequest#authorize method and then use something like $user->authorize('show', $ticket)?
What if we want groups or roles? Should we use some plugin like Entrust and/or policies?
What do you think, what do you do?
Best place I found to put classes that group specific logic that do not fit in standard MVC pattern is completely new folder for Laravel. I name mine Services, probably because I read it somewhere. One of the great things in Laravel (and probably other modern frameworks) is flexibility, you can just pop a folder, add a new namespace and have it contain whatever you need.
As for your example, I would implement a class App\Services\Permissions that would contain all necessary logic for accessing different resources in your application. Then call it's methods wherever you need them, be it Requests, Middlewares or Eloquent Models.
I'm a Laravel 3.x beginner with a CI background.
I'm very acquainted to use controllers rather than routes and I'm having issues trying to use controllers in Laravel.
For example: let's say I have the home_controller and the "about" action. My problem is that I'm only able to access the "about" action by setting a route that points to it - something I think is undesirable.
Is there a way to get the "about" action to work without setting a route?
In laravel, everything can be accomplished using either Routes and/or controllers.
However, using both routes AND controllers is suggested for great flexibility. See this article for more informations and some examples of how to combine routes with controllers.
Anyway, if you want to use controllers (which is perfectly acceptable), you need to register them in your routes.php with Route::controller('yourcontroller') before you can use them.
Everything has to be routed in Laravel. But, you don't have to manually route each method. You could do something along the lines of Route::controller('admin').
See here: http://laravel.com/docs/routing#controller-routing
I like Mike Anthony solution. When you're using only controllers this detect method is everything you have to do - this will register automatically all of your controllers. Best hand free solution so far.
The usual controller registration is, as the guys already mentioned, this:
Route::controller('controllername');
You have to register all controllers like in the example above. It is one line of code per a controller, and it is the rule.
But if you have a static page or a login action (page), a good practice is to create a Route controller (anonymus function), not a classic controller (in controllers folder).
I am moving our current ASP.net website to a MVC3 project and am very new to MVC. Currently we have a 2 level authorization for a superadmin and a admin. Both these levels of authorization get directed to a menu where there are some common and some different pages which they each access. I was wondering how I could structure it such that there will be minimum duplication of controller logic with URLs like -
myURL/SuperAdmin
myURL/SuperAdmin/Users
myURL/SuperAdmin/Users/UserId
Similarly for Admin.
For the above kind of URL I may have to duplicate the controller code (for the Users view) in the SuperAdmin as well as the Admin controllers. As both these access the Users View. I would like to avoid this, but have the same URL. We are making use of the existing business layer entity framework (stored procedures) and not using any LinqToSql. Can I use named routing for this? If so, how? I hope I am making myself clear.
Can someone please help? Any ideas and suggestions will be greatly appreciated.
Thanks,
sdd
I'm not entirely clear on this. If you think you will have code duplication then remove that code into common classes that multiple controllers will access. Sure you can have multiple routes point you to the same controller/action methods (if thats what you meant) but I recommend you don't have multiple URI's (excluding varying parameters) that go into the same controller method. It makes your app a bit hard to follow.
Where do you guys put your static pages, like "home", in an MVC framework? Do you have a "home" controller? A "pages" controller? Do you create actions for each static page?
I'm using CFWheels now, and I'm trying to figure out the best place to put them.
Edit: Apparently CFWheels doesn't require you to create actions for all your views. So you can just create an empty controller and call the views like actions, but not have to write out the blank functions.
CakePHP (and I guess, Ruby On Rails) has a "pages" controller. There is a routing function which redirects requests to /pages/foo to /pages/display/foo. Similarly, / is redirected to /pages/display/home. The display action looks up the views/pages folder for any file with a matching name and renders that.
At the end of the day, a static page is a view without a model, that was returned based on an action the user requested from your server by hitting particular route. :-)
Yes, technically you could expose the direct location of the view resource to the user and rely on the http daemon to go fetch it and return it. However, that means that the resource URL is now tied not to the semantic of the resource you want to expose, but to actual bits. This means that if you want another representation of that same resource, you have to expose it on a different URL.
So, when you create the structure of your web app, think first about the URLs and the resources you want to expose and then think how to implement each resource.
I put my static pages in the database using a simple CMS with a private admin page.
This way, the clients can make simple changes themselves.
In Wheels, you don't even need to create the controller file.
If you create your view here:
views/about/index.cfm
You don't need to create the controller file at all. Then you should be able to just call this with no problems:
http://www.example.com/about