Template inclusion order in new TemplateManifest/ManifestFileFinder implementation

[Ingo Schommer]

Hey guys,

This is a followup to AJShort's announcement on his manifest rewrite:

https://groups.google.com/d/topic/silverstripe-dev/AYmy3CH0PGk/discussion

I'm just writing some examples on how to customize the CMS templates, and

it turns out that by moving most templates from cms/templates to sapphire/admin/templates,

you can't overload them any longer. So not an immediate effect of the new finder implementation.

Just the alphabet striking back ;)

Given that we want the CMS to stay at least as customizeable as in 2.4, 

this long standing issue should be solved before 3.0 final.

The file finder claims it goes depth first, but in fact is breadth first.

So in other words, instead of "module by module", it finds templates based on their depth in the directory tree.

Here's an example of the order:

/cms
/mysite
/sapphire
/zzz_admin
/cms/templates
/mysite/templates
/sapphire/admin
/sapphire/templates
/zzz_admin/admin
/zzz_admin/templates
/cms/templates/Includes
/cms/templates/email
/sapphire/admin/templates
/sapphire/templates/Includes
/sapphire/templates/email
/zzz_admin/admin/templates

I've added zzz_mysite/admin/templates to demonstrate the effect.

This naming and folder structure is required to overload anything in sapphire/admin.

So making it depth first would help (wouldn't need the weird zzz_admin/admin subfolder),

but the main issues remains. First question: Any objections against making it depth first?

I could think of three approaches:

// 1. Simplistic option

$m = new SS_TemplateManifest();

// All other dirs would be included afterwards, sorted alphabetically

$m->setOption('dir_sort', array('sapphire','cms','mysite'));

$m->setOption('dir_sort_callback', ...);

// 2. Declarative option

$m = new SS_TemplateManifest();

$m->addDirSort('sapphire', array('before' => 'cms'));

$m->addDirSort('mysite', array('after' => 'blog'));

$m->addDirSort('mymodule', array('end' => true));

// 3. Priority option in YML config

mysite/_config/000-templates.yml

template_priority: 90 # value between 0 and 100

@Hamish: You've done similar work for the config system, discussion here:

https://groups.google.com/d/topic/silverstripe-dev/dDau6fvUKNo/discussion

What's your recommendation? By the way, is this work in a feature branch somewhere?

Ingo

[Zauberfisch]

good evening,

I am used to php configs, so I can't say if I will like the yml way,
but if all other configs are yml, then it should be yml too.

I really like the idea with priority.
Items sorted by priority and then name/depth. sweet.

On Nov 22, 10:18 am, Ingo Schommer <ingo.schom...@gmail.com> wrote:
> Hey guys,
>

> This is a followup to AJShort's announcement on his manifest rewrite:https://groups.google.com/d/topic/silverstripe-dev/AYmy3CH0PGk/discus...

> @Hamish: You've done similar work for the config system, discussion here:https://groups.google.com/d/topic/silverstripe-dev/dDau6fvUKNo/discus...

[Hamish Friedlander]

Hi Ingo,

I don't use a priority in the config system any more (it was universally reviled), I use an after/before system.

So maybe something like:

mysite/_config/templates.yml:

---

After: sapphire

Before: *

---

SSViewer:

  TemplateLocations:

    - mysite/templates

Which would set mysite templates to override cms and other module templates, but not sapphire templates.

Question, if a template directory isn't mentioned in a config, should it be included by default anyway? Probably, both for backwards compatibility & reducing "gotchas". We could instead provide a default config, but we'd need to be careful then, because you can build loops if you're not careful. For e.g. if you had the above, but also this in the cms module:

---

Before: sapphire

---

SSViewer:

  TemplateLocations:

    - cms/templates

Then the config system would throw an error because of the dependency loop (the cms fragment has to come before sapphire, the mysite fragment has to come after sapphire but before cms, which isn't possible).

More details on the after/before system:

Each fragment of config has a path that looks like:

{module}/{config_filename}#{fragment_name}

Which you can then mention in after or before lines in other fragments. You can leave out later sections, and can use "*" to mean "everything except anything explicitly mentioned in the counterposing option".

For an example, here's the route config in cms and sapphire (sorry for the html mail - let me know if it's unreadable and I'll gist it).

cms/_config/routes.yml:

---

After: 'sapphire/routes'

---

Director:

    Routes:

        'processes//$Action/$ID/$Batch': BatchProcess_Controller

        'admin/help//$Action/$ID': CMSHelp

        'admin/bulkload//$Action/$ID/$OtherID': BulkLoaderAdmin

        'admin/cms//$Action/$ID/$OtherID': CMSMain

        'dev/buildcache/$Action': RebuildStaticCacheTask

sapphire/_config/routes.yml:

---

Name: baseroute

---

Director:

    Routes:

        '$URLSegment//$Action/$ID/$OtherID': ModelAsController

---

Name: coreroutes

After: sapphire/routes#baseroute

---

Director:

    Routes:

        'Security//$Action/$ID/$OtherID': Security

        'db//$Action': DatabaseAdmin

        '$Controller//$Action/$ID/$OtherID': '*'

        '': RootURLController

        'api/v1/live': VersionedRestfulServer

        'api/v1': RestfulServer

        'soap/v1': SOAPModelAccess

        'dev': DevelopmentAdmin

        'interactive': SapphireREPL

Hamish Friedlander

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.

To post to this group, send email to silverst...@googlegroups.com.
To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.

[Ingo Schommer]

FYI, logged a bug report for that: http://open.silverstripe.org/ticket/7085

@Andrew: You mentioned in a different GSOC-related post that

you see module and template priority specification as part of the same project,

maybe you have any feedback for this? Given that you implemented

the TemplateManifest, can you suggest any quick fixes that don't

conflict too much with further development?