Set default view namespace

[thomasjthomasj]

What does this do?

Allows a default view namespace to be set in the App class, making it easier to override views, particularly template views. It will first assume that a relative view path, i.e. one that has the format of ::path:to:view, uses the default view namespace. If the view cannot be found, it will revert to its current behaviour - it will check the most recently used namespace that has been declared within a view and try and find it that way. If it still cannot find it, it will throw an exception as it does currently.

How should this be manually tested?

In a Mothership project, edit the App.php file so the class has getDefaultViewNamespace() method, which returns the view namespace of the main site codebase, e.g.:

<?php

class App extends \Message\Cog\Application\Loader
{
    protected function _registerModules()
    {
        return array(
            'Message\\ImageResize',
            'Message\\User',
            'Message\\Mothership\\User',
            'Message\\Mothership\\ControlPanel',
            'Message\\Mothership\\FileManager',
            'Message\\Mothership\\CMS',
            'Message\\Mothership\\Commerce',
            'Message\\Mothership\\Ecommerce',
            'Message\\Mothership\\OrderReturn',
            'Message\\Mothership\\Epos',
            'Message\\Mothership\\Voucher',
            'Message\\Mothership\\Discount',
            'Message\\Mothership\\Mailing',
            'Message\\Mothership\\Report',
            'Message\\Mothership\\Stripe',
            'Mothership\\Site',
        );
    }

    public function getDefaultViewNamespace()
    {
        return 'Mothership\\Site';
    }
}

Then look for a view override (there are plenty in Ecommerce' checkout) and move it to the main view directory of the project (for instance, you could move /view/Message:Mothership:Ecommerce/checkout/checkout-layout.html.twig to /app/general/resources/view/checkout/checkout-layout.html.twig). Doing this will still not work, as this PR only sets up the capability of overriding views in this way. You will need to edit a view that references this view, for instance the stage-1-review.html.twig view in Ecommerce, and remove the namespace from the extends statement, so instead of having:

{% extends 'Message:Mothership:Ecomerce::checkout:checkout-layout' %}

you will have

{% extends '::checkout:checkout-layout' %}

This will automatically look for a view with a reference of Mothership:Site::checkout:checkout-layout, which can be found in the resources/views/checkout directory of the main project.

You should then check that it does not error if you remove this view, but rather renders the default view in Ecommerce (the one that has no styling)

In a Mothership module, change one of the view extends to use a relative path reference.

This change also works with asset paths. If you add a 'test.js' file in both a module and in the site itself, and link to it in a view within the module using @::assets:js:test.js, it should first look within the declared namespace for the asset file, and if it can't find it, default to the namespace of the module it is called from.

Related PRs / Issues / Resources?

Anything else to add? (Screenshots, background context, etc)

[thomasjthomasj]

This is going to need more work. Currently the way it figures out its current namespace is by checking the most recently used namespace, which is kind of a fuzzy and sloppy way to check.

We propose that we refactor this so that it can register the namespaces by converting the backslash separated namespaces registered in the Loader to colon separated namespaces, and then storing these as an associative array global variable. When rendering a view it can then match the namespace of the controller up against the registered module namespaces and figure it out that way.

It would also be possible to use a different colon separated namespace by registering the modules as an associative array in the Loader, eg:

return [
    'Some:Different:Namespace' => 'The\\Actual\\Namespace'
];