flake8
passed.
JSHint
passed.
Smooth out some wrinkles in review request field rendering.
Review Request #9134 — Created Aug. 14, 2017 and submitted
The way that review request fields were rendered was a bit hodge-podge. The
templatetags that iterated over fieldsets had a handful of special-cases that
theoretically simplified the template, but it wasn't really buying us anything.
In addition, we had three different implementations of rendering the actual
field HTML, including a completely hard-coded one for the summary.This change generalizes everything a bit, adding conditionals in the template
for the special cases of the main fieldset and the summary field. This also
breaks out the actual field HTML into a reusable template. I've also changed
should_renderto be a property on the field, which can be overridden as a
@propertymethod in those cases that need it.
- Ran unit tests.
- Ran js-tests.
- Smoke tested review request fields.
| Description | From | Last Updated |
|---|---|---|
|
What happens to older fields created by extensions that define a should_render method? Seems like they're going to break now. … |
 chipx86
|
|
|
Why don't we still want exception handling here? |
chipx86
|
|
|
Should we put this in a try...finally in case rendering the child nodelist throws an exception? |
 brennie
|
-
-
What happens to older fields created by extensions that define a
should_rendermethod? Seems like they're going to break now. Can we move the template handling for this into the template tag, and have it conditionally check if the method exists and has the old signature, emitting a warning if the old method is used? -
