Introduced renderer to DRY up controllers #9235
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR reduces code duplication all over the codebase and introduces a couple of new concepts - I'm not 100% about them yet so they kind of have temporary names :) Over the next few commits hopefully the concepts will solidify and things will get real names.
To start, we now have a renderer. This has the job of handling everything that happens once we've got our data ready to render:
res.locals.context
res._template
res.render
.Most interestingly, to make this work, all controllers now define a little bit of config, currently stored in
res._route
. (That's a totally temporary location, as isres._template
... when a sensible naming convention reveals itself I'll get rid of the weird_
). This exposes atype
and for custom routes a template name & default.I have a plan to move this forward into a more standardised concept of controllers. This changeset makes sense on its own for now tho...
refs #5091, #9192