Pulling these templates into a project

[Scotchester]

What is the best way to get these templates into your project and keep them in sync with the rest of the site?

Possible options:

• Bower package (I think this is my preferred option.)
• Git submodule
• One-off Grunt task

[himedlooff]

Do the Sheer templates need to be at the root level? If so then the Bower approach would involve an extra step of moving it out.

[Scotchester]

They need to be in the _layouts folder and that folder alone, for now, as best I can tell. I think any of these options will require getting the templates to that folder, or reconfiguring where Sheer looks for them. I talked to @rosskarchner last week about having an _includes type directory to better separate out utility things like macros.html.

[himedlooff]

I think sticking with Bower is a good idea. Keeps the workflow consistent.

[rosskarchner]

Interesting wrinkle, circa 2015--
In Django-land, the obvious thing to do with this repo would be to add _includes and _layouts to the template DIRS:
https://docs.djangoproject.com/en/1.8/topics/templates/#configuration
ala
https://github.com/rosskarchner/cfgov-django/blob/master/cfgov/cfgov/settings/local.py#L75

But, if a project includes both the cfgov-refresh templates and these, there will be naming conflicts-- a template that references "layout-1-3.html" will pull the first one it finds, which probably just depends on the order they are listed in the settings.

[Scotchester]

Thanks for jumping in here, Ross!

In theory, use of this would replace the cfgov-refresh templates, or the owning-a-home templates. There would only be the layout-1-3.html provided by this package.

This DIRS list might make this a bit easier for us, though.

Currently, what I'm doing on fin-ed-resources (see: [ghe]/CFGOV/fin-ed-resources) is bringing this repo in as a Bower dependency, then copying the things it provides to the root-level _layouts and _includes folders via manually-run Grunt task. If we could add the Bower-installed locations to DIRS, we could avoid that copy step:

'DIRS': [
    APP_NAME,
    APP_NAME.child('_layouts'),
    APP_NAME.child('_includes'),
    APP_NAME.child('static/vendor/cfgov-sheer-templates/_layouts'),
    APP_NAME.child('static/vendor/cfgov-sheer-templates/_includes'),
],

[Scotchester]

(I've corrected the accidentally-submitted comment.)

[rosskarchner]

I think there's gonna be a time period of them living side-by side.

That should be fine for the medium-term. It gets a little weird if I was going to, say, port the existing Ask CFPB app to use these base templates, though-- unless I do something like create a bower-ified version of those templates.

(not saying its a bad idea)

[Scotchester]

They shouldn't have to live side-by-side. IMO, if a project implements cfgov-sheer-templates as a dependency, it should remove all duplicate templates from its project source. This may involve creating some new templates that extend what's provided by cfgov-sheer-templates, and it may involve submitting some PRs to update cfgov-sheer-templates to provide missing features, but at no point should multiple templates of the same name be living in the same project. In my ideal world :)

One other problem I realized: cfgov-sheer-templates also contains some static assets (currently, the assets required for the Nemo header and footer shims; in the future, probably universal Flapjack assets), which are also copied by that Grunt task into the appropriate locations in /src. Those files, if they are not copied out of the vendor folder (and they probably shouldn't be), will also need to be incorporated correctly.

[rosskarchner]

That's one place where Django helps-- you can point it at multiple directories, and it will expose all of the files at /static/ (and 'collectstatic' will gather them for deployment)

https://docs.djangoproject.com/en/1.8/ref/settings/#std:setting-STATICFILES_DIRS

[Scotchester]

Nice! Could do the same idea as with the templates, then.