Few days ago I started to learn Laravel and I can't understand one mechanism: there is AppServiceProvider where I can register (bind) my custom classes, interfaces, etc.. But in many tutorials when author creates custom classes for registration them they also creates custom service provider class instead of using "register" method in AppServiceProvider. And I cann't figure out, why they don't use AppServiceProvider?
Also, I looked at other builtin serviceproviders, and found there some methods and fields that are not described in official guide (for example, AuthServiceProvider has protected $policies field). Maybe, understanding this helps me to understand, where I can use standard provider and where custom? But I can't google any link answering this question.
Thank you for your answers.
Mostly it's all about readability of your code. You can probably just put everything in the AppServiceProvider and it will work, but over time, the file will be very long and very hard to orientate in so you might want to separate things and make custom ServiceProviders for each part of your application logic.
It really is up to you how you want to structure your files and folders. As for me, I try to make my files modular (separate a piece of functionality within it's own module, e.g. Authentication is a module). Grouping service providers that are related to this module will be in a separate service provider to avoid cluttering the AppServiceProvider.
Related
I am using AntonioRiveiro/Tracker repo for my laravel app. I would like to add some more functionality to it that it doesn't have out of the box.
But I can't find where its instance gets created, or how to access the Tracker object in my Controllers.
Or how do I extend the tracker object?
So I think the easiest way for you to go about this is the following:
First, make your own ServiceProvider
php artisan make:provider CustomTrackerServiceProvider
Now open up that file, we'll need to make some modifications.
Firstly, we'll need to extend the ServiceProvider that Tracker provides.
use PragmaRX\Tracker\Vendor\Laravel\ServiceProvider as TrackerServiceProvider
class CustomTrackerServiceProvider extends TrackerServiceProvider
The use alias above is not required, but I prefer it for clarity given the similar naming convention to the core framework.
Now you'll need to replace your usage of the PragmaRX\Tracker\Vendor\Laravel\ServiceProvider in your config/app.php file under the providers array
config/app.php
'providers' => [
//other providers and what have you
App\Http\Providers\CustomTrackerServiceProvider::class
]
Now you have the ability to make changes. You can override the default functionality of the core class as long as it's member is not private.
Have a look at the vendor provided file and identify a similar architecture pattern to the vendor maintainer, and you'll be good to go.
The answer to this question provides a solution for (2), I found the answer to (1) here.
To access the tracker object you need to include:
use PragmaRX\Tracker\Vendor\Laravel\Facade as tracker;
Then you'll do something like:
$visitor = Tracker::currentSession();
as described in the documentation.
I want to add my own oauth provider. After reading this, I added a PhabricatorFoobarAuthProvider.php in phabricator/src/applications/auth/provider/ and added a PhutilFoobarAuthAdapter.php in libphutil/src/auth/ and then executed arc liberate seprately. I expected to see Foobar provider to show in this page: localhost/auth/config/new but I didn't. What need I do to reach the goal? Am I forgetting some steps? Thanks.
I use `install_ubuntu.sh` to install phabricator. The layout is like this:
phab
....install_ubunut.sh
....arcanist/
....libphutil/
....phabricator/
So the english is a tiny bit broken but i'll answer this the best that I can. What I assume you are trying to do is figure out is "how can I add my own Oauth provider?". In doing so you came across this magical function that seems to be doing something but your not sure what.
The PhutilClassMapQuery is essential to understanding phabricator and arcanist. If you grep -R "PhutilClassMapQuery" . you will find around 100 different places that it is used. Every place that this is used you as the user are able to load in your own classes that integrate seamlessly with the Phabricator application.
I'll use PhabricatorAuthProvider as an example. If you look here you will notice that this is an abstract class. What the that function does is say load in every class that extends the current class of PhabricatorAuthProvider. So as an example if you look here you can see that this class provides Persona authentication and it does that simply by implementing the needed functions.
I am not going to go through the rest of this but you should be able to figure out the rest based on the above and using this link which shows you how to load your classes into Phabricator.
Hope you enjoy. Phabricator is some of the nicest PHP code that you will find.
In this stackoverflow post,
Get the query executed in Laravel 3/4
Ricardo Rossi provided a great answer about using Kint and a custom class to easily output information about a Laravel query created using the query builder.
I was able to setup Kent using composer but am new to Laravel and haven't used PHP since version 4.
Could someone please provide an example describing how to create a class which can then be called from anywhere. In his example, Ricardo says he uses "DBH::q()".
At the moment, I'm stuck requiring common files just like in good old PHP4 days.
Thanks
You likely want to use psr-0 auto loading with a namespaced class. Here's a post on setting up laravel which says how to do that.
If I understand your question correctly you are asking how to go about using the following syntax DB::q() using your own custom class...
Laravel uses Facades throughout its design which enables you to access classes from anywhere in your app using static style syntax (e.g. Input::get() or Route::get()). I note Fideloper has also provided an answer to your question... He has an excellent tutorial about how to wrap your own custom class in a Facade so you can use this syntax for your own classes and also sidestep the need to inject the dependency in any class that uses it (i.e. once set up correctly it can be called upon anywhere in your app).
Fideloper tutorial is here...
Hope that helps - Good luck
I'd like to use Zend_Tool (ZF 1.9) with my project, but I would like to be able to customize the default output of new files. For example, all Controllers should have a specific header pre-pended to the output with phpdoc markup and licensing information to avoid me having to add this as an extra step.
Also, for this particular project (but not all other projects), I need the controllers to extend something other than the default Zend controller as I have extended that for some specific functionality.
The documentation alludes to the ability to do these things, but it does not make it very clear.
From what I can tell I can set up a ~/.zf directory (on ***nix based systems) and include custom providers there. However, this will be machine-wide as opposed to limited to single project scope. Also, while this will add new providers it does not (seemingly) allow me to customize the functionality of existing providers.
Any help here would be greatly appreciated!
Essentially what Jacob was getting at: what you're talking seems like simple class extending. There's a really simple slideshow introduction to extending Zend Framework here:
http://www.slideshare.net/PHPBelgium/extending-zend-framework-presentation
There are also lots of other resources available online for extending Zend Framework. You can create separate source trees for your different projects, and functionality common to various projects can be added to abstract classes that are in common folders. Something like this isn't common, but I've found it works in those kinds of situations:
class My_Component_HelloProvider extends My_Common_Component_HelloProvider
{
public function say()
{
echo 'Hello from my provider!';
}
// public function do() is inherited
}
class My_Common_Component_HelloProvider
implements Zend_Tool_Framework_Provider_Interface
{
public function do()
{
// do something
}
}
Let me know if this is different from what you're trying to do, but there's no reason you can't build multiple applcation extensions from a single instance of ZF.
You can naturally continue to override when you define the specific classes. You can declare them to be based on your class, rather than the ZF class.
For specific projects, you can modify your classpath to be a custom version of ZF or possibly have a custom override folder. With a custom folder then your changes are not machine wide, but neither is your zend framework. on ***nix based systems, you can leverage symbolic links to keep yourself to one copy of ZF.
Are you trying to modify your source code to include the license headers and PHPdoc? If so, what I have done in the past is have a simple build step that adds the information you need. Each file type can have the appropriate header information. You can have nice tags to tell the system to ignore files, or only run on controllers.
Good Luck,
Jacob
straight to the point :
I am using Kohana, and I am looking at another script written in plain PHP. In the script, I have a class ShoppingCart. If I am to convert the script to Kohana, where am I to put the class, its methods and its properties?
Is it in my existing default controller? Or should I put it in a separate controller? Or as noobie as it may sound, will I put it in the model?
That depends on the specifics of the class I suppose. To be honest I don't know anything about Kohana, but there's probably a place for "vendor files" somewhere. Maybe it's best to place it there and write wrapper functions for it in your controller. If the class already integrates well with Kohana you may instead choose to use it as a controller or model directly. Or you might want to take the time to rewrite it to make it work as a controller...
Only you can evaluate the best place for it, there's no hard and fast rule here.
Kohana has a folder for 3rd party libraries. The main one is under system/vendor, you can put it in you application/ as well.
Many PHP class loaders require details like your filename should be the same as the class name (at least that's what I read in the Kohana documentation) if you want the classes to be automatically loaded.
If you need to use 3rd party code in your app it's recommended that you create a folder in your app / module folder called 'vendor' and place all of that code there.
You can then include the files by calling:
include kohana::find_file('vendor', 'filename');
If needs be you can also create a wrapper for the external library, a good example of this is the email helper which uses the 3rd party Swift email library.
If you're porting your own class to kohana then you need to work out what the class will be doing and categorise it accordingly.
If the class will be fetching items from some kind of database then you should make it a model. Libraries are usually sets of code that you want reuse across controllers / models, such as authentication, calendar generation etc. Controllers are used for passing data from models to your views / libraries.
See the docs for more info
As per kohana convention, you should place custom classes in application/libraries folder. However for this, you need to know how to get the class to work after putting it there. If you can't figure that out, you can do anything like putting it in your controller or making another controller of it, etc.