Refactor core internals to use the Laravel Service Container

[caendesilva]

About

This is an overall goal I'm working towards by making the Hyde Core more modular by utilising the amazing Service Container provided by Laravel. This is a slow progress as I don't want to break anything, and this PR will not create a full switchover, instead I will use it to document what I am doing while I'm doing it, and to encourage collaboration.

The new patterns

The way I am doing this is by creating two new patterns in the Core namespace. The Core is intended to register and bootstrap the critical parts of the Hyde Framework, similar to Laravel Service Providers. The idea is to make it easy to hook into the internal API and change things granularly without breaking stuff.

The new patterns are as follows:

Managers:

These are Contracts (interfaces) that define the methods needed for the implementations.

Providers:

Each Manager Contract has a Provider, which is the default implementation for the Contract.

Practical example

Here is a part of the new interface for managing filesystem related services, as well as the implementation:

namespace Hyde\Framework\Core;

interface HydeSystemManager
{
    public function getProjectRoot(): string;
}

class HydeSystemProvider implements HydeSystemManager
{
    public function getProjectRoot(): string
    {
        return getcwd();
    }
}

As you can see, these are very light classes that are not intended to house logic. Instead it tells Hyde where the logic is housed. If, say, you wanted to change the project root at runtime, you can simply swap out the Provider for your own implementation. How do you make this swap you may ask? That brings us to the next part.

The HydeManager

The HydeManager is in essence a bootstrapper, which acts as a glue binding the Core together.

The HydeManager and HydeManagerContract classes do not conform to the naming syntax of the new patterns, this is intentional as I want to differentiate them. The HydeManager is the class that tells Hyde which contract implementations to load and from where. It also instantiates these implementations and holds them as properties of the class.

The HydeMananger is then loaded as a Singleton in the HydeServiceProvider. When internally accessing a Manager/Provider method, they are accessed through the Singleton.

Overriding the implementations

Note that while I have not yet tested if this works, the way I think it should (and will) work is as follows:

Create a class that extends the HydeManager class, let's call it MyHydeManager. Define any method overrides here, then create a service provider extending the HydeServiceProvider, calling it MyHydeServiceProvider. In your new service provider, swap out the Singleton in your register method for the new MyHydeManager. Finally, in your project's config/app.php, replace the HydeServiceProvider entry with MyHydeServiceProvider.

[caendesilva]

Decided against the source location as it makes it too abstract. A better implementation if one wants to override a page source directory is to extend that specific page model. Then we can make a provider that defines which pages models to use

[caendesilva]

Rethinking again about what actually needs to be changed at runtime.

Currently the only use cases I personally have is to change the root directory and to disable auto creation of folders. If anyone reads this and has ideas for more, let me know. Otherwise I think I will try to simplify this pattern.

[caendesilva]

Scrapping this for now as it adds more complexity then problems to solve. I learned a lot while prepping this, which is what's great about coding in public. And I'll cherry-pick some of the config improvements to master.

[caendesilva]

Scrapping this for now as it adds more complexity then problems to solve. I learned a lot while prepping this, which is what's great about coding in public. And I'll cherry-pick some of the config improvements to master.

Tracking changes in #340