Fix issues using ListEditWidget with more complex sub-widgets.
Review Request #13412 — Created Nov. 14, 2023 and submitted
A couple issues were encountered when trying to embed some complex
widgets (containing a
First, the default row template was not escaped when rendering it in the
template as an option for the view. This is not a security issue, as
this is app-provided HTML, and does not make use of user-provided input
(unless the application is doing something very custom). This has been
updated to properly escape.
Second, IDs weren't being passed in to sub-widgets, which could affect
their ability to render and set up their state. This was made more
complex when sub-widgets had inline scripts or other complexity needed
for setup, particularly because we need to be able to pass in some sort
of default template for a row, and have that customized in the
To resolve that, we now hard-code some placeholder constants within the
template, representing the ID and name, and then fill those in when
change (to avoid disassociating state when reordering rows), and a name
that may change (due to reordering on delete).
Some other optimizations were made to avoid repeated DOM lookups for the
This overall makes it easier to work with more complex sub-widgets
within this widget. There are things it still can't do, like
cooperatively work with a field that wants to clean up on delete, but
that's not an immediate concern.
Tested existing and in-progress usage of the field and widget.