Is there a way to create clients from user interface in Laravel? If I need to allow users to create and manage their own clients, how can I run "passport:client" in a function context in order to create a client on the fly?
I tried by making a OauthClient model and implementing a form that generates the client, but the so created clients are not recognized in requests (they are random strings of 40 characters).
I strongly recommend looking at the source code where the command is handled (and maybe this gist)
There is no need to create an own model class! You can create new clients programmatically by using the Laravel\Passport\ClientRepository class. Simply take one of these options:
Use dependency injection
You can inject the ClientRepository class into your controller/route functions. E.g. in the routes/web.php:
Route::get('test', function (\Laravel\Passport\ClientRepository $clientRepository) {
$clientRepository->create(null, 'MyTest', 'https://example.com/auth/callback');
});
Use the app() helper
In fact also dependency injection but callable from any place of your code, you can use the app() helper:
$clientRepository = app('Laravel\Passport\ClientRepository');
$client = $clientRepository->create(null, 'MyTest', 'https://example.com/auth/callback');
Related
I am creating an API. In this API I am accessing a (permissions) table from a database multiple times, in middleware as well as in controllers. I was thinking, instead of accessing the database multiple times, why don't I call it once and use it multiple times. After calling it once, I could store it in the cache within a service provider. But I am not sure if it is a good way to go because API routes don't load all the services like session.
There are other ways like storing data into the config. Or create a class and make a facade for it and then call it when ever it is needed. But I am curious if the cache would work in API routes and would it be a good idea?
Okay with the advice of #lagbox I created a dead simple class.
namespace App\Helpers;
use App\Permission;
class Provide
{
public $permissions = [];
function __construct() {
$this->permissions = Permission::whereNotNull('route_name')->get();
}
}
This may vary, it's just a class that will keep some collection data in it. I named it provide to keep it generic, just in case that I could need other data than permission in the future. Of course this class could be more detailed but just for storing and returning permissions it is enough.
Then I bound it as a singleton in my AppServiceProvider to run it only once.
public function register()
{
$this->app->singleton('App\Helpers\Provide', function ($app) {
return new \App\Helpers\Provide();
});
}
and when I need it I call it like
$provide->permissions->toArray()
All the features of the collection are available everywhere from the beginning to the end. Yes that may look like an overkill or an abuse of IoC but this über simple approach is in my case a superb solution.
Basically what i want to do is that 1 Controller handels two store functions called like this:
public function singleupload(){
..some code
}
and
public function multiupload(){
..some code too
}
as i continued to define the routes (get/post)
Route::get('/MultiUpload', 'controller#MultiUpload');
Route::get('/SingleUpload', 'controller#SingleUpload');
Route::post('/MultiUpload', 'controller#storeMulti');
Route::post('/SingleUpload', 'controller#storeSingle');
and as i tried to post some data to my database it tells me that there is no 'store' function. So i opened the docs and found this:
POST /photos store photos.store
So my question is can i create two store functions in one controller or do i have to create a different one so every route has its own controller with its own store function?
You are doing some things wrong.
First of all follow Repository Pattern.
You should always write all common functions in Repository which can be accessible in entire Project.
You should use controller only to fetch the request from the Route and pass all the logic to the Repository.
These Process will help you reduce all you coding lines.
Hope this helps !!!
cheers!!
NO you don't need to create new Controller. You can add new action for this.
But it also, depends on the how is your application functionality.
Normally, i personally recommended to create generic function or traits or add the functionality in base controller.
you can handle multiple store functions in one controller there is no need to create 2 different controllers.
I am a beginner starting out in laravel 5.2 and I think these concepts below should be explained more straight forward than just reading documentation.
Service Providers
Service Container
Contracts
Facades
I think a good explanation and examples that can really help beginners understand how these 4 concepts fit together in the framework.
Service provider :
The so called service providers are the heartbeat of your Laravel application. They are the central element of the initialization process where all the relevant and required code is loaded by PHP. This includes all the essentials from the framework itself, but also any own and custom code you need to load.
Inversion of Control, or IoC :
Can't be explained easly (i only have few ideas about this im not a pro)
Facades :
The Facade pattern is a software design pattern which is often used in object oriented programming. A facade is, in fact, a class wrapping a complex library to provide a simpler and more readable interface to it. The Facade pattern can also be used to provide a unified and well-designed API to a group of complex and poorly designed APIs.
A Laravel facade is a class which provides a static-like interface to services inside the container. These facades, according to the documentation, serve as a proxy for accessing the underlying implementation of the container’s services.
MORE
Contracts :
LARACASTS FREE VIDEO
I know this is not enough! what you are asking is complicated stuff a single answer can't be enough
Ok, so first I agree with the others that laracasts is an amazing resource, that will really go into greater detail and break things down very simply.
That being said, the brief overview is as follows:
Service Container (IoC container) is a laravel core process that allows you to load objects with their dependencies gracefully. For example, If I have a controller method like this:
public function update(Request $request, $id)
{
...
}
IoC container is smart enough to resolve the Request and load up all the dependencies associated with the Request class to make sure it gets instantiated properly.
It also allows you to instantiate classes without having to fully pass along all the dependencies as follows:
class ProductRepo(Product $product)
{
public function get($id)
{
...
}
}
I can reference this class without loading it with dependency injection as follows: (make sure to pass in full namespace)
app('App\ProductRepo')->get($id);
This allows me to not have to pass in a Product Object, Laravel is smart enough to resolve the Product object because the IoC container is doing the magic behind the scenes.
Service Providers are a place for you to lace in custom behavior when booting up or instantiating a class. For example, Laravel by default uses a class called the EventServiceProvider. This class's job is to configure the Event system in Laravel to make sure to include all the custom event listeners you create. So if I wanted to make sure that when the EventDispatcher is being loaded up, it brings in all the necessary dependencies.
Contracts are really simple. They are just an allusion to php object oriented concept of Interfaces. This concept states that there are classes that establish rules. For Example:
interface SearchableInterface
{
public function search($data);
}
class BinarySearch implements SearchableInterface
{
public function search($data)
{
...
}
}
This states that any class that implements the SearchableInterface, must have a function search that accepts one parameter. This creates a 'contract' that any classes that implement the SearchableInterface will have to have this function, or the application will throw an error.
This is great for using interchangeable pieces (siblings) and not having to worry that the class is missing a function you need.
Last but not least is the Facade. I love facades. In a nutshell all this is doing is creating a static representation of a class that was not defined statically. So lets say I have a class that will get a document from S3.
class S3
{
public function get($file)
{
...
}
}
Without a facade you would first have to instantiate and then call get on the class in order to get something from S3.
$s3 = new S3;
$s3->get('myAwesomeFile');
Laravel allows you to easily register Facades so that you can just use this statically for readability and convenience.
S3::get('MyAwesomeFile');
All of this has been an over-simplification of each concept, but goes into some detail about some of the basics of each concept. Hope this helps!
I'd like to get the path to a package public directory (css etc) based on the package alias.
Is there anything already built into the laravel framework?
In other words something like:
public_path('myalias');
When I'm talking about alias, you would typically "alias" a module by adding the following within your service provider's boot method:
$this->package('namespace/package','alias_name');
For those wondering why someone might want to do this:
We are running a multi domain/subdomain application that makes use of a central piece of code for all of the domains and then specific packages per domain (I'll refer to them as funnels).
Each funnel has its own controllers that can possibly extend base controllers to implement their own functionality while re-using code where they can. They also have their own views.
The funnel refers to its own views by way of something like:
View::make('funnel::path.to.view')
The way we accomplish this is by doing some business logic on page load to only load the FunnelServiceProvider related to that particular domain and aliasing it to "funnel". This way our base controllers can also refer to funnel and not be tied to a particular packages views,includes,blocks etc.
My hope is to do something similar on the views so that I can simply call something like get_funnel_path() to get the path to the funnel that is currently being loaded.
The value could then be used to load css,js,images etc without worrying about the funnel path.
This would allow us to simply copy and paste views from one domain to the next without having to modify all of the paths in potentially multiple files. We could also make use of globally included files in all/most of the views.
An example of this might be the head. The head section should be the same for 99% of the files, however the path where it loads its resources should change based on the funnel.
We use the same naming conventions for css files as well as use sass, imports, merging for all of the funnels; so only the path needs to change.
You can do something like this although it will only work with your own packages and require a bit of work. Because the alias is not really stored somewhere you can easily access you have to do that yourself.
First create some kind of class to store your package names in. I called mine PackageManager:
class PackageManager {
private $packages = array();
public function addPackage($fullName, $alias){
$this->packages[$alias] = $fullName;
return $this;
}
public function getPublicPath($alias){
if(!isset($this->packages[$alias])) return public_path();
$path = 'packages/' . $this->packages[$alias];
return public_path($path);
}
}
Now let's register that class as a singleton in a service provider:
$this->app->singleton('packagemanager', function(){
return new PackageManager();
});
Then, in every package you want to register, add this call in the boot method right next to $this->package():
$this->app['packagemanager']->addPackage('vendor/package', 'alias');
After that you can do this anywhere in your application:
app('packagemanager')->getPublicPath('alias');
If you want a shorter syntax, add this helper function somewhere:
function public_package_path($alias){
return app('packagemanager')->getPublicPath($alias);
}
And just do:
public_package_path('alias');
I'm updating an php web application that is becoming multilingual, based on the Zend MVC framework, and I'm trying to figure out the best approach to passing the translation object to different classes/layers.
Most of my translation is done at the View level, but there are a few cases where I need to return status messages from custom libraries.
I could just create a property for the library and set the translator, but I'm wondering if there is a better way to integrate a translator object into an existing application?
Hold the users lanaguage in a Memento, and pass that through the program logic, when you need to do that translation use it identify the language.
If using Zend_Translate, it's best option to use register.
Zend_Registry::set('Zend_Translate', $translate);
This way all classes can find it automatically (Zend_Form, Zend_Validate, ...)
You could always instantiate the translator in the bootstrap.php so it is available to all classes as a global. That's how I'd do it since you probably need to use it everywhere. It isn't elegant, but it keeps you from having to add code wherever a class needs to throw an exception or return an error message.
If you don't have that many controllers setup can you not extend the base controller and instantiate the translator there? It should be available for use throughout the system then.
Something like this to extend:
<?php
class BaseController extends Zend_Controller_Action
{
public function init()
{
//setup translation object
}
}
?>
You might want to consider to use a dependency injector container, where the translator is an entry that you pass to the objects you need, without manually constructing the object. That way you can easily test and make more high quality (and testable) code
See other question here
How to use dependency injection in Zend Framework?
or this article about plugging ZF 2 DI into ZF1
http://adam.lundrigan.ca/2011/06/using-zenddi-in-zf1/