Some actual code #1
Conversation
rendering cfgov-refresh pages with django-sheerlike
Move the GlobalRequestMiddleware up the stack
- using the single SheerTemplateView generic view - no longer need to spell out the inclusion of _includes and _layouts from a Sheer site - no longer need to specify static dirs, if they are coming from a Sheer site
| }, | ||
| }, | ||
| { | ||
| 'BACKEND': 'django.template.backends.jinja2.Jinja2', |
There was a problem hiding this comment.
Do we not want this before the DjangoTemplates engine? Wouldn't this cause this to always try django templating first and then fall back on Jinja2?
There was a problem hiding this comment.
That's a good point-- you're probably right
|
Not sure if this comment should be here or django-sheerlike but currently django cannot access the templates in cfgov-refresh because the templates are now located in |
|
|
||
| BASE_DIR = os.path.dirname(os.path.dirname(os.path.abspath(__file__))) | ||
|
|
||
| CFGOV_REFRESH = Path(__file__).ancestor(5).child('cfgov-refresh') |
There was a problem hiding this comment.
Why are we using ancestor instead of parent?
There was a problem hiding this comment.
Also concerning my other comment, this could be CFGOV_REFRESH = Path(__file__).ancestor(5).child('cfgov-refresh').child('dist') to solve that problem.
There was a problem hiding this comment.
because the equivalent of ancestor(5) would be parent.parent.parent.parent.parent? ;)
There was a problem hiding this comment.
I think I'd prefer to keep CFGOV_REFRESH pointed at the top level project..., we can add .child('dist') in the SHEER_SITES setting.
There was a problem hiding this comment.
Addressed in latest commit
There was a problem hiding this comment.
Yeah I realized the parent() thing during lunch /facepalm 😟
Should we create a PROJECT_ROOT setting instead and then get the parent from that? Seems like we'd find putting the settings file where we want useful?
There was a problem hiding this comment.
That might make sense for deployment scenarios, but I really think the simplest thing here is assuming both repos are sitting next to each other.
Adds a 'gruntserver' command that extends 'runserver' to run 'grunt watch' in any directories you speicify with settings.GRUNT_WATCH,
|
New feature: a 'gruntserver' command that extended 'runserver' to run 'grunt watch' in the background, |
| @@ -0,0 +1,6 @@ | |||
| unipath>=1.1,<=2.0 | |||
| django>=1.8,<=1.9 | |||
| git+https://github.com/rosskarchner/django-sheerlike.git#egg=sheerlike | |||
There was a problem hiding this comment.
Do we want to keep you as the owner here? Just until your PR get's pulled in?
There was a problem hiding this comment.
Just until the PR's get pulled in-- there's no code in the CFPB version of sheerlike yet.
There was a problem hiding this comment.
Latest commit fixes this
|
Depending on if the django-sheerlike PR gets merged before this, this is a-okay. If that PR does get merged, then I suggest changing the requirements.txt file to pull from the cfpb repo of django-sheerlike rather than yours before merging this. |
|
sheerlike is merged and this is ready to be updated. |
|
👍 |
|
thanks! |
Most notable for URL configuration, for mapping URL's to django-sheerlike views