API: Look for templates of namespaced classes in subfolders.

[sminnee]

This change will mean that SilverStripe\Control\Controller will look for its
template in templates/SilverStripe/Control/Controller.ss.

In order to preserve some backwards campatibility, non-namespaced classes
can have the templates stored in any template subfolder, but once you
add a namespace to a class, the namespaced path expression will need to
be a subfolder of /templates or themes//templates.

Layout and Content templates are stil supported as special template type,
Includes still functions but is a no-op. Other template subfolders should
not be used.

To do

• Docs
• Namespaces in includes

[dhensby]

test failure :(

[sminnee]

The test failure is caused because tests/controller/themes/controllertest/Controller.ss or tests/view/themes/layouttest/Controller.ss are being inadvertently included as unthemed templates for Controller, because themes aren't expected to be found in side tests/.*/themes/. I'll have a look at the previous behaviour and get something closer to it, if I can.

[sminnee]

Needed some if(isset())s.

[sminnee]

Needs docs, and the use of arbitrary folders should throw a deprecation notice

[wilr]

So if templates/SilverStripe/Control/Controller.ss has <% include Foo %> Foo.ss should not live in templates/Includes/?

SilverStripe in this case because the vendor is SilverStripe so if you install 3rdParty/silverstripe-bar then to override those templates they would be localled in templates/3rdParty/... If everything will just be in templates/SilverStripe it seems an unnecessary folder depth

Can we get the documentation updated alongside the PR?

[sminnee]

So if templates/SilverStripe/Control/Controller.ss has <% include Foo %> Foo.ss should not live in templates/Includes/?

Oops, yeah... I hadn't thought that one through.

Probably the best best is to allow namespaces on includes, so we could <% include App\Regions\Foo %> and this would follow whatever namespace-to-folder-mapping was set up for App\Regions.

Using namespace semantics would be another option (so that Foo in the above example would resolve to SilverStripe\Control\Foo) but I think that will confuse more than help. Include statements aren't frequent enough for the verbosity to be a serious concern.

SilverStripe in this case because the vendor is SilverStripe so if you install 3rdParty/silverstripe-bar then to override those templates they would be localled in templates/3rdParty/... If everything will just be in templates/SilverStripe it seems an unnecessary folder depth

This PR matches PSR-0 folder conventions, which creates a lot of depth. But, yes, the SilverStripe namespace is only used for projects in the silverstripe/ composer vendor, if that's what you're getting at.

Building on this PR, I'd like to introduce more of a PSR-4 style resolver, where we can map subfolders to namespace prefixes. However, this simpler PR is intended to be the minimum necessary to let us start namespacing controller classes, so I don't want to bloat it.

Can we get the documentation updated alongside the PR?

Yeah, good call. At a minimum I'll put some terse docs into the PR.

[wilr]

@sminnee Include statements aren't frequent enough for the verbosity to be a serious concern. I'd be surprised if people aren't using includes as much as us (a certain telco provider has 145 in the includes and children folders) Things like displaying a users avatar with tooltip and edit link is reused across multiple different namespaces.

[sminnee]

OK, fair point, but is specifying namespaces a problem, and if so, what would be a better approach? Lumping all includes into a single unnamespaced folder feels far from optimal.

We could have flags for selecting which namespaces to search, etc, but I'm worried about pre-emptively bloating out the number of special tags in the template system.

[sminnee]

Ultimately, I guess you could do this, if we expected full namespaces:

templates/Includes/Something.ss

 <h1>Something</1h> 

templates/App/PageType/Page.ss:

<% include Includes/Something %>

OK for a first-cut?

[axyr]

I think Also that Includes are heavily used. At least we do as well..

[sminnee]

OK, I've made those changes now. Ready for merge? I'd like to get this in so that we can start namespacing core classes that have templates attached.

[tractorcow]

I've tested this out locally, and am getting some really weird behaviour.

does it need a rebase maybe?

[tractorcow]

Rebasing fixes it. :D

[tractorcow]

Merged with 19646d1