Subfolders under "Layout" theme directory.

[Patrick Nelson]

After studying how the TemplateManifest works, is there any particular reason why we can't instead have the ->handleFile() method derive the "type" (e.g. "Includes" or "Layout") straight from the base directory within the root of the template directory instead of the immediate parent of the template file? The latter method prevents you from having sub-directories for layouts and only affects layouts. This doesn't affect includes at all, it appears, since I'm able to place those anywhere I want and they'll still get incorporated into the final template.

This would be extremely useful since larger sites with a reasonably large number of custom layouts could benefit from a little more organization. This shouldn't deviate from convention per se, since you'd still have to have the layout file somewhere underneath the base "Layout" directory.

e.g.

/themes/mysite/templates/Layout/SubDirectory/MyPage.ss

... instead of this, along side potentially 20 other unrelated layouts that belong to the same theme:

/themes/mysite/templates/Layout/MyPage.ss

Just wondering if there are any thoughts on this and if this is the sort of change anyone would be interested in or particularly against for any specific technical reason. Thanks!

- Patrick

[Loz Calver]

I can’t think of any technical reason why we couldn’t do that off the top of my head, though I’m not sure whether being able to put “includes” anywhere is accidental or a design decision. You can achieve similar separation by using themename_context as a top-level theme directory. For example, instead of:

/themes/mysite/templates/Layout/Shop/MyPage.ss

You can have:

/themes/mysite_shop/templates/Layout/MyPage.ss

The template manifest will pop off the ‘_shop’ part and treat it as part of the main theme.

Loz

[Patrick Nelson]

Yeah -- I'm seeing the contextual shift happening there with the underscore. It looks like my test changes are working fine along with that. Would this be the sort of think you'd think should be a PR against 3 or master? It shouldn't change existing functionality (that's the goal, at least) but only extend a little extra functionality. I've already accounted for any potential non-theme templates and it only overrides that $type value if everything lines up as expected (and within the contextual theme).

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at http://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.

[Patrick Nelson]

Got some demo code up here, for reference: https://github.com/silverstripe/silverstripe-framework/pull/4739

[Patrick Nelson]

On another note, does anyone have any clue how I can properly replace the SS_TemplateManifest without changing more core files (like Core.php or editing the actual class file itself)? That is, I've got enough modifications to core that I'm keeping track of already and one less change I need to worry about, the better in terms of maintenance and security.

Right now this is registered in "Core.php" which is called after my site's _config.php (where I'd want to procedurally configure/override this sort of thing):

SS_TemplateLoader::instance()->pushManifest(new SS_TemplateManifest(

   BASE_PATH, project(), false, $flush

));

The problem is that not only does this get called after my _config.php (meaning it would just override my code) but the SS_TemplateLoader itself is also impossible to override. Maybe it would make more sense to also edit/update core to use the injector as well? That is, calling something like "singleton()" which turns around and calls Injector::inst()->get(), a nice centralized framework method of defining a singleton which I can override via YAML. Coincidentally that very function is defined in the same file where the homegrown (duplicated?) singleton pattern is used on that SS_TemplateLoader, so that could use some refactoring anyway.

singleton("SS_TemplateLoader")->pushManifest(Injector::inst()->create("SS_TemplateManifest",

   BASE_PATH, project(), false, $flush

));

That second ->create() is needed since SS_Template doesn't extend "Object" (yet) so the ::create() syntax isn't available there.