Is there a built in or library based way to implement generic Eloquent/Model based views in Laravel for simple CRUD endpoints?
At the moment I am writing the logic for index, store, destroy, update manually, but all the code is essentially the same.
e.g.
public function destroy($id)
{
$customer= CustomerInfo::find($id);
$customer->delete();
}
I'm more used to Django and the DRF which implements a ModelViewSet class which handles all (most) of the logic for simple CRUD applications.
Implement generic Eloquent/Model based views in Laravel for simple CRUD endpoints
I'm not sure about that but Laravel provides route to model binding, which shortens your code. There's also resource controller which is already pretty much declare all needed methods for you. What's left is quite minimal. So after using model binding and resource controller, your destroy() method may look like:
public function destroy(CustomerInfo $customerInfo)
{
$customerInfo->delete();
}
But the method name and its agrument is already declared like a placeholder, you just write delete() line. More about model binding and resource controller
Use single artisan command to have CRUD endpoints all in one.
php artisan make:controller PhotoController --resource
Because of this common use case, Laravel resource routing assigns the typical create, read, update, and delete ("CRUD") routes to a controller with a single line of code. To get started, we can use the make:controller Artisan command's --resource option to quickly create a controller to handle these actions:
Related
I have a Laravel controller with a 'store' method. i.e. store(Request $request).
For the view I want to embed a livewire component and then utilize the existing controller 'store' method (behind the scenes) from a livewire component method. Is this possible? Currently, I'm running into the problem that there is no Request object since I'm no longer making the call from the existing route/view (i.e. POST /orders).
public function oms_order()
// this method provides the POST /orders leveraging
// Controllers\OrderController#store
{
$this->refId = app('App\Http\Controllers\OrderController')->store($this->jsonOrder);
}
Argument 1 passed to App\Http\Controllers\OrderController::store() must be an instance of Illuminate\Http\Request, null given, called in D:\xampp\htdocs\jade\livewire_hpp\app\Http\Livewire\Oms.php on line 26
I can remove the 'Request $request' from the store method but then that breaks the standard Laravel POST /orders route.
I was hoping to use the existing laravel app as the backend/API and add the livewire bit for a demo. Any advice is welcome.
I don't think it is a best practice to call a controller function from another class. If you want reusability, I suggest refactoring code by creating a separate class with a store method which accepts only required attributes and saves a record.
Then you can use this method in multiple places. It is easier to test also.
It is difficult to give an exact answer before seeing your store method.
I want to create a function for doing all kind of CRUD operation. This function will be called from any controller's inside a function. Then the function will search for a table/Model, then based on operation type it will do the rest things.
It will be good to implement this kind of function that can be used commonly? It will increase the complexity of CRUD? Or, should do the CRUD in controllers' functions?
My project is pretty big. Im thinking to write a function to do CRUD.
Welcome to stackoverflow.
You should consider using a controller, like ProductsController, and inside it, you should have a funcion for every action (store, update, etc).
Doing all of this in a single function only adds unnecessary complexity to the project and this isn't how things should be done.
As a starting point, execute this command on you project: php artisan make:controller ProductsController --resource. This will create an well structured controller for Products CRUD actions.
Hope you find this helpfull.
I found nothing about definitions/differences between resource and plain controllers.
What is the difference between them?
When you simply create a command with **php artisan:make controller ControllerName** it will create a file with no functions in it. And you can add your functions on your own.
But if you create controller with resource then it will simply give you with all the functions you need for CRUD operation.
And with plain controller you have to create route for each functions. But with resource controller you simply add Route::resource('/routename','ControllerName'); then it will add all the routes for your index,create,store,show,edit,update and delete function.
I hope this answer is helpful for you..
Simply definitions of controllers type is:
Resource controller is used when you perform all CRUD operations.
Plain Controller is used for anything performed manually.
--plain
php artisan make:controller Mycontroller --plain
This will eventually make a plain constructor since you are passing the argument --plain.
The controller that you have created can be invoked from within routes.php file using this syntax below-
Example:- Route::get('base URI','Mycontroller#method');
A basic controller code will look something like this app/Http/Controller/MyController.php:
<?php
namespace App\Http\Controllers;
use Illuminate\Http\Request;
use App\Http\Requests;
use App\Http\Controllers\Controller;
class MyController extends Controller
{
//
}
Resource Controllers
The resource route of Laravel allot the classic "CRUD" routes for controllers having a single line of code. This can be created quickly using the make:controller command (Artisan command) something like this"
php artisan make:controller MyController --resource
Actions Handled by Resource Controllers:
Verb URI Action Route Name
GET /photos index photos.index
GET /photos/create create photos.create
POST /photos store photos.store
GET /photos/{photo} show photos.show
GET /photos/{photo}/edit edit photos.edit
PUT/PATCH /photos/{photo} update photos.update
DELETE /photos/{photo} destroy photos.destroy
More Details:- Resource Controllers
In Laravel, are all controllers only supposed to have the basic CRUD methods, as shown in the link below?
https://laravel.com/docs/5.3/controllers#resource-controllers
That is, should the only methods in a controller be:
index()
create()
store()
show()
edit()
update()
destroy()
Thanks.
No.
A controller can have methods named however you want!
If you are creating a RESTful controller, then the names of the methods make sense.
When you create a Resource Controller, then Laravel will save you the pain of writing the routes (you can use Route::resource)
For example: you can do this in YourController.php
function tada() {
return "Tadaaaa";
}
and then in your routes.php, you define a route like
Route::get('tada', 'YourController#tada');
And visiting that route will present you with the string Tadaaaa
Have fun!
No, You can have your own functions too. This is just a boilerplate that Laravel provides you to start with.
I would like to more in depth knowledge about using static methods . I'm using laravel 5.2 framework for my application.
In my application mostly i have used static functions For example i have model class name like post and method name is get_post() and its declared as static only if i missed static keyword in laravel it throws error
class Post extends Eloquent(){
public static function get_post(){
return DB::table('post')->get();
}
}
In my controller i will call this above method
Post::get_post()
How could i avoid to call this method as static ? as per the PHPMD 1.4.0 rule
Anyone please explain clearly.
Laravel's Eloquent is called via the static method, so I'm not sure how to avoid this. By the way, instead of the functions you wrote, you can of course write
Post::all();
Another abstraction possibility is to use the Repository Pattern, where the Controller doesn't call the Model's functions directly, but rather something like
$activePosts = $postRepository->getActiveAndApproved();
where the $postRepository would do some of the heavy lifting on Laravel's Eloquent model doing e.g. ->where('something', true) and stuff like that - Symfony has this already a bit stronger included in their framework.
See https://bosnadev.com/2015/03/07/using-repository-pattern-in-laravel-5/ for more detailed instructions.
Seeing also that Laravel uses Facades a lot, which is a simplified way to access functions in the service container (e.g. see config/app.php or https://laravel.com/docs/5.2/facades for more infos), it might be difficult to avoid static function calls.