flightphp
Is there way to integrate PHP-DI with Flight?
Hi, I am interested to use a dependency container(Ex: PHP-DI) with Flight. Is there any way of adding/binding it with flight?
This is actually pretty easy to do. Provided you have PHP-DI installed, it looks like this:
<?php
// Add the container to Flight
Flight::register('container', 'DI\Container');
// Use the container
$container = Flight::container();
See http://flightphp.com/learn/#extending.
You can now use it in pretty cool ways:
<?php
require '../vendor/autoload.php';
class Greeting
{
public function __construct() {
$this->name = 'John Doe';
}
public function hello() {
echo "Hello, {$this->name}!";
}
}
Flight::register('container', 'DI\Container');
Flight::route('/greeting', [Flight::container()->get('Greeting'), 'hello']);
Flight::start();
No need to instantiate the Greeting class or even bind it to the container 😀
@hyyan @defunctl I'm curious on your thoughts about other ideas for a DI Container of some kind?
I was notified about this thread because of my earlier comment.
Looking at the solution I suggested above, I don't think it's ideal. An object is basically instantiated for every route definition (the container will use the same instance if you use the same class for multiple routes though).
Having used Flight in several internal projects in the past, I think this is one of its weaknesses. You need to either instantiate controllers yourself, or only use first class functions, closures or static methods. Neither of them are ideal.
It would be great if you could just do:
Flight::register(Greeting::class, fn() => new Greeting());
Flight::route('/greeting', [Greeting::class, 'hello']);
and Flight would then take care of instantiating the right object only when needed.
It would be even greater if it would be capable of autowiring, making the Flight::register call redundant.
Just my five cents.
Just my five cents
I counted at least 6 cents in there ;)
Yeah this is something I need to look more into how the framework currently does this, and what would be cool. It needs a simple container manager of some kind.
If you're looking for a small dependency injection container, I made a simple PSR-compatible container (that also uses reflection to resolve dependencies, if needed, to make it as "plug'n'play" as possible). Feel free to use it as inspiration, or simply "copy/paste" it into Flight if you want.
https://github.com/magnus-eriksson/container
If you want some extra pair of hands with something, let me know.
@magnus-eriksson Dang you like simple stuff :) Simple stuff is good stuff.
So looking over your container, I could add a couple pseudo methods to Flight, but honestly how it registers and handles classes is........like your container with different words. I mean it doesn't spell out "I'm a container manager" but it's pretty close. Maybe just needs some PSR-7 flair and it'd nail it.
Having used Flight in several internal projects in the past, I think this is one of its weaknesses. You need to either instantiate controllers yourself, or only use first class functions, closures or static methods. Neither of them are ideal.
Fat-Free kinda handles this with $f3->route('GET /url', 'Controller->method'); and it will dynamically create the object and route the context into it, I think this would be easy to add to Flight.
I wanted to implement https://github.com/abmmhasan/InterMix here but the library requires PHP 8.2 atleast. I understand we're keeping 7.4 for some compatibility but old users could pick up old versions isn't it?
@abmmhasan looks like flight does support php 8.2. composer.json
Yes it supports, but if you require it, won't make problem in <8.2?
@abmmhasan it shouldn't be a problem. as flight core haven't used any PHP 8 features
@abmmhasan it shouldn't be a problem. as flight core haven't used any PHP 8 features
The InterMix minimum requirement is 8.2, means it will cause issue below that. So, if I require it in flight, this will cause issue. Because, when composer install flight below 8.2, it will install but will throw error during Intermix installation and halt the total process. I hope you understood.
You could probably install with composer require flightphp/core --ignore-platform-reqs If that doesn't work, then there is probably a tweak that needs to be made to the composer.json file to allow for it. Cause it totally should be fine.
It sounds like you have two different conversations :-)
@abmmhasan Are you suggesting that Flight should add that "interMix" library as a dependency in their composer.json for interMix dependency manager? And then if someone installs Flight on PHP 7.4, it won't work because of the interMix dependency? If not, then it's very unclear what you mean and what it has to do with this ticket.
It sounds like you have two different conversations :-)
@abmmhasan Are you suggesting that Flight should add that "interMix" library as a dependency in their composer.json for interMix dependency manager? And then if someone installs Flight on PHP 7.4, it won't work because of the interMix dependency? If not, then it's very unclear what you mean and what it has to do with this ticket.
Yes! That is what I thought to suggest in the first comment of mine. Unfortunately it is gone other way.
So I think it's fine if you want to add intermix in your own projects, but I don't think I should merge it into the Flight codebase. It already has a "container manager" of sorts that is built in and adding intermix would conflict with that (plus it'd be a lot of work to make it work correctly with the package).
FYI, a DIC is now part of Flight https://docs.flightphp.com/learn/dependency-injection-container