Pulling these templates into a project about cfgov-sheer-templates HOT 10 CLOSED

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.

from cfgov-sheer-templates.

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.

from cfgov-sheer-templates.

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

from cfgov-sheer-templates.

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.

from cfgov-sheer-templates.

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'),
],

from cfgov-sheer-templates.

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

from cfgov-sheer-templates.

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)

from cfgov-sheer-templates.

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.

from cfgov-sheer-templates.

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

from cfgov-sheer-templates.

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

from cfgov-sheer-templates.