I would like to load a list of classes dynamically. The general idea would be to have a sort of manifest/config file that contains an array list of classes and then they would "automatically" be loaded into my application instead of needing to manually do something like
use App\Controllers\UserController;
use App\Controllers\ContractController;
use App\Controllers\SubscriptionController;
etc...
It seems there must be some way to achieve this as the Laravel framework does something similar with service providers. You register the classes once in config/app.php and then these provider classes are auto loaded onto the app.
If you are looking for a native/homemade solution without any PSR0/4 convention or composer package manager, you can consider use spl_autoload_register and __autoload to make your own logic to resolve the classes.
But i would strongly recommend composer and PSR4 standarts for this.
Here is the example of a customer resolver/loader class
https://www.php.net/manual/en/function.spl-autoload-register.php#102180
Related
There are many questions regarding loading custom helper classes in Laravel. However, none of them focus on the loading them with proper initialization.
As of Laravel version 5.3 we can use psr-4 autoloading which is autoloading the entire app/ directory. However, classes are loading but never initialized.
I have my helper class inside the app/helpers/support.php. This class has a constructor, where I want to load some important configuration in order to make the helper usable.
So how can I load my helper but ALSO initialize it properly in Laravel? Right now I am simply working-around the problem by using new \App\Helper\Support(); inside AppServiceProvider.php.
Edit: I'm using the following approach to maintain my helper class:
Best practices for custom helpers on Laravel 5
It seems like what you have is a service. Rather than creating an instance, you can declare it in your app service provider and inject it as a dependency when you need it.
In your register method:
$this->app->bind(\App\Helper\Support::class);
You can now use dependency injection to get an instance of your class. You can also make an instance like this:
app()->make(\App\Helper\Support::class);
If you only want one instance to exist at any given time, use singleton rather than bind.
I recommend reading the service container documentation:
https://laravel.com/docs/5.5/container
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'm using CodeIgniter and I have a few utils that I want each controller (that is, each controller file) to have access to.
The question is: where to put these?
I thought of helpers, but the CI documentation talks only about extending existing helpers, not making your own. I'm sure that doesn't mean I can't make my own helpers, but it does mean I don't know how they should be built (procedural? Methods of the global CI instance? etc)
I also considered hooks, but this is a poor fit I think as I'm not extending core functionality.
Or is there some other way I'm missing?
It's been a while since I've done this but I believe I used two approaches.
Creating a new, custom helper that goes into /application/helpers, following steps noted from this answer: CodeIgniter: Create new helper?
Creating a new library class into /application/libraries which I also activate in the autoload configuration found in /applications/config/autoload.php. This way it's always available to my controllers when I need it. CI has good documentation on this one (http://ellislab.com/codeigniter/user-guide/general/creating_libraries.html).
I did it simply by adding a file to the application/helpers folder (maybe I created that folder - I can't remember) and then loading them in the usual way.
I'm starting to write a application in php with one of my friends and was wondering, if you have any advice on how to implement module support into our application.
Or is there a way how to automatically load modules written in php by a php application? Or should i just rely on __autoload function?
And we don't need plugins that are installable via a web interface, we just need some clever way to associate web pages of our project to some classes (they will render the page) so index.php can call the right class and retrieve it's generated sub-page.
And we are not using any kind of framework, for now at least.
Re your comment: Autoloading in conjunction with strict file naming would be totally enough in this case IMO.
You could define a specific namespace (not in the new PHP 5.3 namespace way, just in the sense of a common prefix to names), e.g. Module_* for module class names.
You could then organize your modules in directories with class files that contain exactly one class definition, for example:
/modules/Mail/index.php // defines class Module_Mail
/modules/Database/index.php // defines class Module_Database
/modules/Image/index.php // defines class Module_Image
Your autoloader function would then, whenever a Module_* class is requested:
$Database = new Module_Database("localhost", .....);
include the correct file from the right directory.
That's the way e.g. the Zend Framework does it, and does so pretty well.
Consider choosing a more specific namespace than Module_ to assure interoperability with other scripts and applications if that is an option in the future.
Slightly related: In a PHP project, how do you organize and access your helper objects?
It sounds like you are looking for a way to organise the different tasks that each page needs to carry out. In this case, take a look at the MVC pattern. It provides a simple way to seperate your data access (models) and how you render/present information (views).
You can map pages to functions with ease. If you store the information in an array of mapped values, and then use a function to compare the requested URL with each of the URLs in the array. Such an array could look like this:
$urls = array(
'/' => 'index',
'/aboutus/' => 'aboutUs',
);
There are several articles that discuss how to implement it in PHP in a couple of hours. This article is a very simple guide. I am not a fan of their use of the registry pattern but reading through should provide you with enough information as to how you can implement it yourself.
Regarding autoloading, you can also use spl_autoload_register, to define several (more than one) autoload functions, so each module can set up it's own implementation of autoloading.
All you need here is an MVC architecture, with one Controller class associated with each "module".
If you are not against using a framework, go for Zend MVC
It allows you to have the following principle :
An URL like this : http://yoursite.com/my-module/edit
Will more or less automatically call the editAction method in the MyModuleController class.
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.