Hi all,
Please let me know if this is a good fit for an OEP and I'll put one
together. Also let me know if you would also find such a feature useful!
*Issue:* I and others would benefit from a way to load course-wide
JavaScript and CSS assets. There are numerous use cases for this:
- Logging custom events (this alone make the platform even more valuable
for conducting research)
- Consistently styling course content (e.g., by creating classes for
things like callout boxes or image alignment)
- Loading useful JS libraries for things like graphing or code syntax
highlighting
- Trying experimental features (e.g., a course-material search bar;
again, complete with event logging for research)
*Existing workaround:* It's possible to do this in today's platform, but it
requires adding <script> or <style> tags *to every single vertical of a
course*. Clearly this is suboptimal; it increases deployment effort
(especially when conducting multi-course experiments) and may needlessly
increase network traffic.
*Proposed solution: *Add a new policy key (name TBD) for course-wide assets:
{
"web_assets": [
"/static/mystyles.css",
"/static/experiment.js",
"//somecdn.com/library.js"
]
}
*Proposed implementation:* The courseware template already receives and
renders an XBlock fragment (which includes JS and CSS resources);
additional resources could simply be added to this fragment when the
courseware context is created
<https://github.com/edx/edx-platform/blob/add4d3bce3bd5a9a1a5ce4f3cbf9d416c6eb1ee2/lms/djangoapps/courseware/views/index.py#L373-L437>.
This approach leverages the existing XBlock/Django infrastructure to handle
de-duping and rendering, so I expect little code would be needed for the
actual implementation.
*Possible concerns & mitigation strategies:*
- Security. Again, though, the ability to include arbitrary JavaScript
in a course *already exists*... this feature just provides a more
elegant way to do so course-wide. It is possible that making it easier
would lead to wider script usage and thus increase the odds of users
creating a vulnerability; this could be mitigated by (1) adding a stern
warning to the policy key description about including scripts only from
trusted origins, or (2) limiting this feature to /static/* files if it's a
really big concern.
- Support. Platform hosts such as edX should make it clear that this is
a power-user feature that would carry *no support* beyond that for
current <script> and <style> tags (i.e., the platform guarantees that your
scripts will make it into the page, but you're on your own if they don't
work or if something breaks due to platform changes). As with security
above, it's possible there will be more complaints/support requests from
users simply because of wider script/CSS usage, though good documentation
and a warning in the policy key description should hopefully keep these to
a minimum.
...Thoughts?
Martin (MITx graduate research fellow)
--
You received this message because you are subscribed to the Google Groups
"General Open edX discussion" group.
To view this discussion on the web visit
https://groups.google.com/d/msgid/edx-code/bbab60d8-eeee-4a4c-935d-75715b7ec33a%40googlegroups.com.
