Thanks for the reply! Followup thoughts on some of your points below: - 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.
...hat-tip to Peter Pinch for that idea ;-) - 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. Yeah, I see what you're saying - there's definitely a risk of vestigial libraries being loaded with this approach (or libraries just being loaded earlier than needed). On the other hand, XBlocks also don't seem to me like a great fit for syntax highlighting or similar use cases... some specific concerns: 1. Developing new XBlocks requires enough know-how than it's likely out of reach for course authors (compared to, e.g., dropping in the script/CSS files for PrismJS <http://prismjs.com/#basic-usage> to add syntax highlighting course-wide) 2. XBlocks have to be accepted/installed into the platform before being used [I think?], while scripts/CSS resources can be added immediately by course authors 3. XBlocks can't currently be nested inside <problem> or <html> modules, so they're not great for things that might appear interspersed with text like code examples or graphs - 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. > Agreed, though hopefully this will be less of an issue when HTTP/2 takes over sometime in the not-too-distant future =) The fact that static assets are cached should help in the meantime... it looks like edX sets the Cache-Control max-age to 1 year, and external JavaScript CDNs probably have fairly efficient caching behavior too. Let me know where I should go from here. Thanks! Martin On Monday, August 15, 2016 at 11:13:33 AM UTC-4, Andy Armstrong wrote: > > 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 <martin...@gmail.com > <javascript:>> 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/msgid/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 | an...@edx.org <javascript:> > > 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/24c480ae-231b-4285-a7d6-dd0f37bf855e%40googlegroups.com.
