PHPackages                             mattferris/application - PHPackages - PHPackages  [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register)

1. [Directory](/)
2. /
3. [Utility & Helpers](/categories/utility)
4. /
5. mattferris/application

ActiveLibrary[Utility & Helpers](/categories/utility)

mattferris/application
======================

A PHP application loader

1.0(6y ago)01311BSD-2-ClausePHPCI failing

Since Jan 6Pushed 6y ago1 watchersCompare

[ Source](https://github.com/mattferris/application)[ Packagist](https://packagist.org/packages/mattferris/application)[ RSS](/packages/mattferris-application/feed)WikiDiscussions master Synced 2mo ago

READMEChangelog (2)Dependencies (5)Versions (6)Used By (1)

Application
===========

[](#application)

[![Build Status](https://camo.githubusercontent.com/a44fd6ab86659172799d4b31047b1310c07619f807415c704eb804edd8b7f7d3/68747470733a2f2f7472617669732d63692e6f72672f6d6174746665727269732f6170706c69636174696f6e2e7376673f6272616e63683d6d6173746572)](https://travis-ci.org/mattferris/application)

A PHP application bootstrapping framework.

The framework is built on the concept of components. Each component is responsible for configuring itself, registering services, subscribing to events, etc. This means you just add the components you want to your application and run it! The only thing that is required to configure an application is a dependency injection container that implements `MattFerris\Di\ContainerInterface` (which in turn extends `Interop\Container\ContainerInterface`)

A simple HTTP application might look something like:

```
use MattFerris\Application\Application;
use MattFerris\Di\Di;

// setup your application by adding components to it
$app = new Application(new Di(), [
    '\MattFerris\Events\EventsComponent', // event handling
    '\MattFerris\Http\Routing\HttpRoutingComponent' // HTTP request handling
]);

// then run it by passing a startup callable to run()
$app->run(['\MattFerris\Http\Routing\HttpRoutingComponent', 'run']);
```

The `HttpRoutingComponent` has a static method called `run()` that provides some additional bootstrapping to start the request handling process. You could also supply your own `callable` to `$app->run()` if you wanted.

Components
----------

[](#components)

A component might be anything from an individual function to an entire library. In Application terms, a project (i.e. the code) only becomes a component when the projects's configuration and initialization are wrapped into a neat package, represented as an class implementing `MattFerris\Component\ComponentInterface`. Typically, this component class would live in the top-most namespace of your project.

For simplicity, your component class can just extend `MattFerris\Application\Component`.

```
namespace My\Project;

use MattFerris\Application\Component;

class MyProjectComponent extends Component
{
}
```

When extending `MattFerris\Application\Component` you get a component that will automatically load providers from within the same namespace. So given the above component, you can just create providers that live within the `My\Project`namespace.

```
namespace My\Project;

use MattFerris\Provider\ProviderInterface;

class EventsProvider implements ProviderInterface
{
    public function provides($consumer)
    {
        // register events, etc...
    }
}
```

This `EventsProvider` will now be automatically loaded at application boot.

Providers
---------

[](#providers)

A components only real job is to plug providers into the framework. Providers are where the heavy-lifting happens, and are responsible for registering services with service containers, registering event listeners with event dispatchers, supplying routing information to HTTP request dispatchers, etc. A provider must implement `MattFerris\Provider\ProviderInterface` which requires a single method be present called `provides()`.

Be default, there are no provider types. Components must register provider types during initialization.

```
// provided by mattferris/bridge-components
use MattFerris\Bridge\Components\Di\DiComponent;
use MattFerris\Di\Di;
use MattFerris\Application\Application;
use My\Project\MyProjectComponent;

$app = new Application(new Di(), [
    DiComponent::class,
    MyProjectComponent::class
]);
```

`DiComponent` registers a `Services` provider type. You could now defined a `ServicesProvider` in order to register services.

```
namespace My\Project;

use MattFerris\Provider\ProviderInterface;

class ServicesProvider implements ProviderInterface
{
    public function provides($consumer)
    {
        // $consumer will contain an instance of the service container
        $container = $consumer;

        // register a service
        $container->set('MyProjectService', new MyProjectService());
    }
}
```

`ServicesProvider::provides()` is always passed an instance of the configured service container. Likewise, `EventsProvider`s will be passed an instance of the event dispatcher, and so on.

Provider Types
--------------

[](#provider-types)

So far, we've talked about *global* provider types. *Global* provider types can be registered by components in two way. For components extending `MattFerris\Application\Components`, it's as easy as defining the `$provides`property in the component's class definition.

```
namespace My\Project;

use MattFerris\Application\Component;

class MyProjectComponent extends Component
{
    protected $providers = [
        [
            'MyProjectType' => [
                'consumer' => MyProjectConsumer::class,
                'scope' => 'global'
            ]
        ]
    ];

    // ...
}
```

The *consumer* is the type of instance that will be passed to a providers `provides()` method. In this case, it will be an instance of `My\Project\MyProjectConsumer`. Because scope is set to `global`, the component will automatically register the provider.

For standalone components (those not extending `MattFerris\Application\Component`), registration of provider types is done by having the component class implement `MattFerris\Provider\ProviderInterface`, and using `provides()` to manually register the types.

```
namespace My\Project;

use MattFerris\Component\ComponentInterface;
use MattFerris\Provider\ProviderInterface;

class MyProjectComponent implements ComponentInterface, ProviderInterface
{
    public function provides($consumer)
    {
        // $consumer will contain an instance of MattFerris\Application\Application
        $consumer->addProvider('MyProjectType', MyProjectConsumer::class);
    }

    // ...
}
```

For components extending `MattFerris\Application\Component`, you can also define *local* providers for use within the scope of the component. This gives you some flexibility in isolating intialization of your component as required.

```
namespace My\Project;

use MattFerris\Application\Component;

class MyProjectComponent extends Component
{
    protected $providers = [
        [
            'MyLocalType' => [
                'consumer' => MyLocalProjectConsumer::class,
                'scope' => 'local'
            ]
        ]
    ];

    // ...
}
```

Advanced Component Initialization
---------------------------------

[](#advanced-component-initialization)

In some cases, components may have dependencies on each other. It's possible to defined different intialization passes so that components can be initialized in such a way that these dependencies can be satisfied.

```
use MattFerris\Application\Application;

$app = new Application($di, [
    [ 'Component\Satisfying\DependenciesComponent' ], // pass 1
    [ 'Another\Component\DependingOnFirstComponent' ] // pass 2
]);
```

By simply passing an array of arrays, you can break down component intializtion into as many passes as is required to successfully bootstrap your application.

###  Health Score

29

—

LowBetter than 59% of packages

Maintenance20

Infrequent updates — may be unmaintained

Popularity10

Limited adoption so far

Community9

Small or concentrated contributor base

Maturity67

Established project with proven stability

 Bus Factor1

Top contributor holds 100% of commits — single point of failure

How is this calculated?**Maintenance (25%)** — Last commit recency, latest release date, and issue-to-star ratio. Uses a 2-year decay window.

**Popularity (30%)** — Total and monthly downloads, GitHub stars, and forks. Logarithmic scaling prevents top-heavy scores.

**Community (15%)** — Contributors, dependents, forks, watchers, and maintainers. Measures real ecosystem engagement.

**Maturity (30%)** — Project age, version count, PHP version support, and release stability.

###  Release Activity

Cadence

Every ~561 days

Total

3

Last Release

2294d ago

Major Versions

0.2 → 1.02020-02-03

### Community

Maintainers

![](https://www.gravatar.com/avatar/9d3d46e7fdc93a3d67119773bdae779e281a87f2d70e95568a969c72205aedf7?d=identicon)[mattferris](/maintainers/mattferris)

---

Top Contributors

[![mattferris](https://avatars.githubusercontent.com/u/1687325?v=4)](https://github.com/mattferris "mattferris (23 commits)")

###  Code Quality

TestsPHPUnit

### Embed Badge

![Health badge](/badges/mattferris-application/health.svg)

```
[![Health](https://phpackages.com/badges/mattferris-application/health.svg)](https://phpackages.com/packages/mattferris-application)
```

PHPackages © 2026

[Directory](/)[Categories](/categories)[Trending](/trending)[Changelog](/changelog)[Analyze](/analyze)