The cache invalidation check was previously occuring every time either
the `set` or `get` function was called on the cache. However, the cache
invalidation check is based on the jsrev which is static for the
lifetime of the page.
This change moved the invalidation to happen during the setup of the AMD
module such that it only happens one time per storage type (Local +
Session).
We only use the jsrevPrefix to determine if the cache should be
invalidated, but the prefix that we were using is based on the new
jsrev.
For example, the jsrevPrefix will be:
hash(wwwroot + '/ + config.jsrev) + '/jsrev'
Where config.jsrev is the _current_ (new) jsrev.
As a result when searching for the jsrev used to store the data which is
currently in the storage cache, no key is returned, and we instead set
an 'initial' value and the cache is not cleared
This patch changes the jsrevPrefix to be:
hash(wwwroot) + '/jsrev'
Since the wwwroot does not change, the key remains static for the
current site. As a result, when the jsrev is bumped via a Moodle cache
purge, we are able to correctly fetch the old jsrev from the cache,
determine that the jsrev has changed, and purge the cache.
This includes a minor restructure of the autocomplete JS to make use of
promises and improve tracking of pending JS.
In particular it improves the way in which throttled text input is
handled to ensure that the behat does not continue until:
- typing is fully complete; and
- all possible ajax requests have been sent; and
- all possible ajax requests complete; and
- the suggestions are updated.
A number of conditions existed where behat would move on to the next
step too early in a race condition effect between Behat and Autocomplete.
A template can include itself - e.g. by looping over the context children and rendering a tree.
Ensure this promise still resolves.
Example: admin/tool/lp/templates/competencies_tree.mustache.
The form-autocomplete module uses three Mustache templates
core/form_autocomplete_input, core/form_autocomplete_suggestions and
core/form_autocomplete_selection. However, it did not support executing
the JS that is eventually part of those templates.
It's possible for the backdrop to be created during the show, before the
modal is actually fully shown.
This check is unnecessary because the getBackdrop() function always
returns a value and will always succeed.
Custom AJAX handlers for the form autocomplete fields can now optionally
return string in their processResults() callback. If a string is
returned, it is displayed instead of the list of suggested items.
The string is displayed same way as we inform about no available
suggestions.
When using the AJAX autocomplete field, it allows JavaScript to add
custom HTML to selected options. For example, the user field from
the assign roles page includes an icon and other information by the
user's name.
Once you submit the form and the page reloads, there was no way to
provide this information back to the autocomplete field. HTML
<option> tag was used for the value names but it may only contain
text, not tags, so including it in the normal value did not work.
This change adds a new option for the autocomplete field that lets
you include HTML to override the default (text-only) value of the
label used to represent each option.
Jun Pataleta