I am using an interface to handle different payment options.
The thing is in my controller I get the bank slug but based on that slug I decide which class Bank in my case to use to process the payment. My controller:
public function sendPayment($request, PayBank $bank_transacton)
{
here I want to reference the SentToBank interface and
send payment class that I get in return from checkBankImplementation function//
SendToBank()->sendLoanApplication($bank_transaction);
}
method to check for the slug so I know which payment service to sent to the interface:
public static function checkBankImplementation($bank_slug) {
switch ($bank_slug) {
case "firstbank":
return new app\FirstBank\Client();
break;
case "secondbank":
return new app\SecondBank\Client();
break;
default:
return null;
}
}
my interface :
<?php
namespace App\Banks;
interface SendToBank {
public function sendLoanApplication($bank_transaction);
}
1- your app\FirstBank\Client() and app\SecondBank\Client() needs to implement the SendToBank interface.
2- From your controller, you have to create the proper object using your static method.
3- Call the sendLoanApplication method on that object
Something like that:
public function sendPayment($request, PayBank $bank_transacton)
{
$bankClient = Class::checkBankImplementation($bank_slug); // You need to change the class name with the one actually implementing the checkBandImplementation method and extract the proper $bank_slug from the request
$bankClient->sendLoanApplication($bank_transaction);
}
Related
I'm trying to add a custom assertion to the TestReponse class so I can make something like this:
$response = $this->json('POST', '/foo/bar');
$response->myCustomAssertion();
I tried creating an App\TestResponse class that extends the original one and then binding it in the App\Provider\AppServiceProvider class.
public function register()
{
$this->app->bind('Illuminate\Foundation\Testing\TestResponse', function ($app) {
return new App\TestResponse();
});
}
But $response->json() is still returning the original one and not my own implementation.
How can I extend the TestResponse class?
If you want a little more fine-grained control, you can also extend the Illuminate\Foundation\Testing\TestResponse, as you have done, and then override the createTestResponse method in your TestCase class to return an instance of your custom response class:
// Laravel 8 and above
protected function createTestResponse($response)
{
return tap(App\TestResponse::fromBaseResponse($response), function ($response) {
$response->withExceptions(
$this->app->bound(LoggedExceptionCollection::class)
? $this->app->make(LoggedExceptionCollection::class)
: new LoggedExceptionCollection
);
});
}
// Before Laravel 8
protected function createTestResponse($response)
{
return App\TestResponse::fromBaseResponse($response);
}
From Illuminate\Foundation\Testing\Concerns\MakesHttpRequests.
The TestResponse class uses the Macroable trait so you can add macro functions at runtime.
TestResponse::macro('nameOfFunction', function (...) {
...
});
You can add this to a Service Provider's boot method or somewhere before you need to make the call to that macro'ed method.
I have the following Notification entity:
As you can see, there is a field called "objectId" where I want to store the related object id depending on the notification type. Then I add the notification to an email queue. When the queue gets processed I have a problem to fetch the object from the specific service class. For example:
Notification Type 1: UserService::getUser($objectId)
Notification Type 2: CompanyService::getCompany($objectId)
So how could I define that relations without having troubles to add more and more notification types. It feels bad to inject all the needed services and handle it through thousands of "if this than that" :)
If you injected the object instead of the id, you wouldn't need to call an additional service inside the notification to get the appropriate instance.
If the Notification doesn't need to know about what kind of object its using, just depend on an interface that both User and Company implement, and inject those objects directly into Notification.
E.g.:
interface EmailNotifiableEntity {
function getLabel()
function getEmailAddress()
}
class User implements EmailNotifiableEntity {
public function getLabel() {
return $this->getName() . " " . $this->getFullName();
}
public function getEmailAddress() {
return this->getEmailAddress();
}
}
class Company implements EmailNotifiableEntity {
public function getLabel() {
return $this->getCompanyName();
}
public function getEmailAddress() {
return this->getNotificationsEmail();
}
}
class Notification {
public function __construct(EmailNotifiableEntity $entity) {
$this->entity = $entity;
}
public function send() {
$address = $entity->getEmailAddress();
$label = $entity->getLabel();
// do your thing to send your notification
}
(Implementation is a bit bare-bones, so take what you need and build upon it). This way, when you instantiate your Notification you inject the depended upon entity without knowing its specific kind.
this supposed to be an MVC framework
(i am learning by doing)
class load{
public function model(){
// some code...
[...] = model[$modelName] = new $modelName();
}
}
this class handles all load option in to the controller..
class _framework{
public $load; // object
public $model; // array
function __construct(){
//some code...
$this->load = new load();
}
}
this is the framework of the controllers
the controller extends this class.
edit:
it should use like this:
class newController extends _framework{
public function index(){
$this->load->model('modelName'); // for loading the model.
$this->model['modelName']->modelMethod(); // for use the model method.
}
}
my problem is where the [...].
how can I get the new model to the array in the framework class??
If you want to get an array out of your model object,
you can define its public method toArray:
class modelName {
public function toArray () {
$array = ...; // get your array here
return $array;
}
}
Then you can call it from outside and get your array:
$myArray = $myModel->toArray();
Your model should encapsulate its data and make them accessible via API like that.
I would not call an array a model though. A model is a layer with many classes serving the purpose of the model - storing your data, peforming their validation, whatever other data-related business logic and providing API to access the data.
Also it is common to capitalize your classes.
I recently watched this video and wanted to change my Laravel controllers so that they had their dependencies managed with Laravel's IoC container. The video talks about creating an interface for a Model and then implementing that interface for the specific data source used.
My question is: when implementing the interface with a class that extends Eloquent and binding that class to the controller so that it is accessible from $this->model, should I also create interfaces and implementations for the Eloquent models which may be returned when calling methods such as $this->model->find($id)? Should there be different classes for the Model and the ModelRepository?
Put it another way: how do I do new Model when my model is in $this->model.
Generally, yes, people doing that pattern (the repository pattern) have an interface which have some methods defined that your app will use:
interface SomethingInterface {
public function find($id);
public function all();
public function paged($offset, $limit);
}
Then you create an implementation of this. If you're using Eloquent, then you can make an Eloquent implementation
use Illuminate\Database\Model;
class EloquentSomething {
protected $something;
public function __construct(Model $something)
{
$this->something = $something;
}
public function find($id)
{
return $this->something->find($id);
}
public function all() { ... }
public function paged($offset, $limit) { ... }
}
Then you make a service provider to put it all together, and add it into app/config/app.php.
use Something; // Eloquent Model
use Namespace\Path\To\EloquentSomething;
use Illuminate\Support\ServiceProvider;
class RepoServiceProvider extends ServiceProvider {
public function register()
{
$app = $this->app;
$app->bind('Namespace/Path/To/SomethingInterface', function()
{
return new EloquentSomething( new Something );
});
}
}
Finally, your controller can use that interface as a type hint:
use Namespace/Path/To/SomethingInterface;
class SomethingController extends BaseController {
protected $something;
public function __construct(SomethingInterface $something)
{
$this->something = $something;
}
public function home() { return $this->something->paged(0, 10); }
}
That should be it. Apologies on any errors, this isn't tested, but is something I do a lot.
Downsides:
More code :D
Upsides:
Able to switch out implementations (instead of EloquentSomething, can use ArraySomething, MongoSomething, whatever), without changing your controller code or any code that uses an implementation of your interface.
Testable - you can mock your Eloquent class and test the repository, or mock your constructor dependency and test your controller
Re-usable - you can App::make() to get the concrete EloquentSomething anywhere in your app and re-use the Something repository anywhere in your code
Repository is a good place to add additional logic, like a layer of cacheing, or even validation rules. Stock mucking about in your controllers.
Finally:, since I likely typed all that out and STILL DIDN'T ANSWER YOUR QUESTION (wtf?!), you can get a new instance of the model using $this->model. Here's an example for creating a new Something:
// Interface:
public function create(array $data);
// EloquentSomething:
public function create(array $data)
{
$something = this->something->newInstance();
// Continue on with creation logic
}
Key is this method, newInstance().
I've used $newModel = $this->model and it's worked for me.
I'm only interested in handling GET or POST requests, so I designed this abstract class to determine which request has been made and to subsequently call the appropriate function. I would really appreciate feedback on this. Thanks!
PS I think this should be a community wiki, but I'm not sure how to set it as that.
abstract class AHttpRequestHandler
{
public function handleRequest()
{
if($_SERVER['REQUEST_METHOD'] == 'POST') {
$this->handlePostRequest();
} else if($_SERVER['REQUEST_METHOD'] == 'GET') {
$this->handleGetRequest();
} else {
$this->handleIllegalRequest();
}
}
abstract protected function handleGetRequest();
abstract protected function handlePostRequest();
protected function handleIllegalRequest()
{
throw new Exception('Illegal request detected in HttpRequestHandler::handleIllegalRequest().');
}
}
In response to comments:
I will only be handling one or the other (GET or POST), never both at the same time.
Either an HTML form will be submitted via POST, or a redirect will be made with a query string, which will be a GET request. I am not familiar with how a mixed request could be made (both GET and POST), but since this is a personal project I have control over whether it happens or not.
I use the AHttpRequestHandler class (above) by implementing the handleGetRequest() and handlePostRequest() methods in a sub-class, which is and abstract controller, AController. Then, for each page of my CMS, I create a sub-class of AController, such as ImageUpload or ImageDetailsEditor. I can provide more details if it will help.
Here are the AController, Controller, and View classes:
AController
abstract class AController extends AHttpRequestHandler
{
protected $view;
public function __construct()
{
$this->handleRequest();
}
protected function handleGetRequest()
{
throw new Exception('handleGetRequest not yet implemented.');
}
protected function handlePostRequest()
{
throw new Exception('handlePostRequest not yet implemented.');
}
abstract protected function initView();
}
Controller
class Controller extends AController
{
protected $content;
public function __construct()
{
$this->view = new View();
parent::__construct();
}
protected function handleGetRequest()
{
$this->content = 'GET Request';
$this->initView();
}
protected function handlePostRequest()
{
$this->content = 'POST Request';
$this->initView();
}
protected function initView()
{
$this->view->content = $this->content;
$this->view->display();
}
}
View
//An over-simplified view for example use only
class View
{
public $content;
public function display()
{
echo "<p>$this->content</p>";
}
}
The actual use:
require_once 'Controller.php';
$controller = new Controller();
First of all you can make a GET request and a POST request in the same time. Think of a form that you post but the url has some variables in the query ( get ).
1.I don't understand the need for such a class but the first thing you could do is make two separate classes for post and get that extend the AHttpRequestHandler class. That way you only need an abstract function handleRequest that you will implement in the child classes.
2.You should apply "Intention Revealing Names". Your class should be RequestHandler and your methods should not contain Request in them. You know that from the class name.
3.Think about this: you might need to handle the post request in one controller. So you will have to add the second abstract method each time just to respect the abstract class.
4.You should not make circular calls between classes ( The Hollywood principle ). handleRequest is called from the child class, and then the parent calls handleGetRequest or handlePostRequest from the child.
Like I said, you are the developer, you know each controller what will use:POST or GET ( what about COOKIEs? ), so you can handle them at controller level without the need to extra classes just for the sake of it.
see ref
see ref
see ref
see ref
And the Controller should receive a request (command), not extend the request to keep things apart. Have no catch phrase for that, perhaps seperation of concerns. That's an extension to 1. above but only if you really need a request object.
Having an abstract class for requests is a good idea and it is there in all frameworks. But I dont think its good to extend this class by all controllers. A better solution will be to separate this to two, an abstract request class and base controller class. In request class you can have methods to identify whether it is a get request or post request, like
class Request{
public function isPost() {
return ($_SERVER['REQUEST_METHOD'] == 'POST');
}
public function isGet() {
return ($_SERVER['REQUEST_METHOD'] == 'GET');
}
}
Also we will have a base controller class with at least the following options
class Controller
{
public $request;
public function __construct() {
$this->setRequest(new Request());
}
public function setRequest(Request $request) {
$this->request = $request;
}
}
All our client controllers will extend the base controller as usual. The advantage of this method is client controllers will have the freedom to determine the request type. if they want to make use of GET and POST request at a time, that also will be possible. The above given is of course an incomplete one. You need to add more methods to the base classes or not is your choice.