Hi Martin, Thanks for this. The use cases you describe are important, so it would be great to talk through how it can be addressed. I'm not sure if this should be handled as an OEP or not, so I posed that question in our OEP Slack channel (https://openedx.slack.com/messages/open-edx-proposals/).
I have a few thoughts to add to your initial proposal: - I like the simplicity of what you are proposing. Using the XBlock runtime's pre-existing loader makes a great deal of sense for the reasons you laid out. - I think some of your use cases would be better handled through XBlock dependencies. For example, IMO a complex feature like code syntax highlighting should be associated with a particular XBlock, rather than being added to an Advanced HTML block. Having the assets tied to the course means that even if the block in question is removed, the assets would still be loaded. It would be better to have them requested on-demand by only the blocks that need them. Having said that, we don't have a mechanism in XBlock to allow multiple blocks to share the same library. - I'd like to consider how such a mechanism should interact with AMD-style loading. We have had some preliminary experimentation with combining XBlocks with RequireJS, and I think it is important to take that into account. - There are performance implications to loading a number of individual files like this. Having said that, it would be difficult to have individual courses contribute files to the static asset pipeline, since courses can be created/imported after the LMS has been stood up. - We might want to make this feature be something that can be disabled if a given installation is not comfortable with giving this power to its authors. As you point out, the power is already there through multiple other mechanisms, so maybe this isn't a concern. Thanks, - Andy On Fri, Aug 12, 2016 at 1:39 PM, Martin Segado <[email protected]> wrote: > 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/ms > gid/edx-code/bbab60d8-eeee-4a4c-935d-75715b7ec33a%40googlegroups.com > <https://groups.google.com/d/msgid/edx-code/bbab60d8-eeee-4a4c-935d-75715b7ec33a%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- *Andy Armstrong* edX | UI Architect | [email protected] 141 Portland Street, 9th floor Cambridge, MA 02139 http://www.edx.org <http://www.edxonline.org/> [image: http://www.e-learn.nl/media/blogs/e-learn/edX_Logo_Col_RGB_FINAL.jpg?mtime=1336074566] -- 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/CAG2ZmnBzq9oDgNAHCKgHth2JNEfDMTRJXOdbX6sq6cKOcnDDgw%40mail.gmail.com.
