The old code set the output-encoding to None, which means, I want
Unicode strings as output. This made Mako pass markupsafe objects to
"unicode()", which applied all the escaping. Then the result would be
given to Django, would would html-escape it again, resulting in
over-escaping.
By setting the output-encoding to utf8, we use filters.encode.utf8
instead, which is aware of Markupsafe, which avoids the over-escaping.
FEDX-93
These are developer only pages, so can not be seen in production
environment. On devstack, you can access these pages in LMS and
Studio at:
/template/ux/reference/pattern-library-test.html
This is the second attempt to enable the Pattern Library. The
first attempt broke Django Templates and didn't work correctly
with right-to-left styling.
TNL-4115. Previously, course updates (which are intended to be posted with
dates, for sorting in the LMS) could be authored in studio with a valid
date, nothing, or a random string as the "date" for the update. As there
is no validation for this in studio, everything succeeded with no warning.
However, the LMS has problems parsing some of these values, and barfs when
loaded by learners.
The fix does two big things:
- gracefully handles invalid dates in LMS. These updates are now treated as
having a date of today, for sorting purposes.
- turns on validation in studio. Now, it is not only impossible to enter
invalid dates in studio, but notifications will draw the course author's
eye if any invalid updates were previously saved.
Test additions for this commit:
Adds:
- unit test for LMS parsing
- Jasmine test to confirm invalid dates cannot be set by the user
-also adds event to setAndValidate instead of using a global object
- fix for lettuce test
-It is no longer valid to enter the string "January 1, 2013" as this test
had been doing. Keyed-in entries must use MM/DD/YY format.
This includes the course key/path for a given contentserver request,
whether or not the asset is locked, cacheable, has been modified, etc.
This should give us some better insight as to what sort of requests are
coming into the contentserver to figure out whether or use of a CDN in
front of these assets is as efficient as effective as it could be.
Before this commit, calling the student_view on a capa problem would
cause it to render an empty placeholder <div>, wait for the
DOMContentLoaded event to be fired, and then make AJAX requests to the
the problem_get handlers to retrieve the HTML it needed to render the
actual problems. This can significantly increase the end user load
times for pages, particularly when there are many problems in a
vertical.
This commit takes a very conservative approach and has the server side
add the rendered HTML into a new data-content attribute on the <div>
enclosing the problem. When Capa's JS initialization runs, it grabs
from that data-content attribute rather than reaching over the network
for an AJAX request.
I had attempted to make it somewhat smarter and push the rendered
problem straight into the document instead of relying on the
data-content attribute. This was faster, and should be our long term
goal. However, it caused odd bugs, particularly around MathJAX
rendering, and I never quite tracked the issue down. I'm still going
forward with these changes because it's significantly better than the
current situation that students have to deal with, and we can make the
JS more performant in a future iteration.
[PERF-261]
