Hi Martin, The conclusion from Slack is that this is a good candidate for an OEP. You can read about the process here:
https://open-edx-proposals.readthedocs.io/en/latest/ You might also want to look at this PR that extends OEP-1 to support product changes: https://github.com/edx/open-edx-proposals/pull/17 We're all new to the OEP process, so thanks for volunteering to be a guinea pig! Let us know if you need help moving forward. Thanks, - Andy On Mon, Aug 15, 2016 at 3:00 PM, Martin Segado <martin.seg...@gmail.com> wrote: > 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> >> 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 | an...@edx.org >> >> 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/ms > gid/edx-code/24c480ae-231b-4285-a7d6-dd0f37bf855e%40googlegroups.com > <https://groups.google.com/d/msgid/edx-code/24c480ae-231b-4285-a7d6-dd0f37bf855e%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- *Andy Armstrong* edX | UI Architect | an...@edx.org 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/CAG2ZmnD7fkOx-bewMfATaSUA8Wh6swvGamvgUqgfkh9TQxBGJg%40mail.gmail.com.
