In ~Palm and earlier, all built-in XBlock Sass was included into CMS
(and LMS) styles before being compiled. So, if a site theme was meant to
affect built-in XBlock styling, those changes would be manifested
directly in the base CMS CSS that is included into every single Studio
page. When the user provided the `?site_theme` querystring parameter,
which is intended to allow devs & admins to view Studio through a given
theme, CMS would look up the given theme and serve the corresponding
base CMS CSS, which would affect the built-in XBlocks views (as
expected).
After ~Palm, built-in XBlocks styles are handled more similarly to to
pure XBlock styles, in that they are only requested when CMS tries to
render the block. In Studio, blocks are not rendered by the original
request, but by a subsequent AJAX request to the `/container_preview`
enpoint. Thus, passing the `?site_theme` query parameter to the original
request will apply the given theme to Studio's chrome, but the theme
will _not_ apply to built-in XBlock views, whose CSS is now loaded via
async request.
To fix this, we simply pass Studio's querystring parameters (including
`?site_theme`) along to the `/container_view` AJAX request. This will
cause CMS to correctly serve the built-in XBlock CSS from the theme
specified by `?site_theme`, rather than whatever the current theme is.
Part of: https://github.com/openedx/edx-platform/issues/32292
- adaptation asides to be imported from the XML
- updating SplitMongo to handle XBlockAsides (CRUD operations)
- updating Studio to handle XBlockAsides handler calls
- updating xblock/core.js to properly init XBlockAsides JavaScript
The function initializeXBlock() expects a DOM element, and is passed one in most
cases. However, when adding a new XBlock component in Studio, the function is
passed a jQuery object, which ends up being forwarded to the actual
initialisation function of the XBlock.
It turns out that loading JavaScript with $.getScript
causes Chrome to treat the file as an XHR request
and not JS. I've switched over to using RequireJS
to load the URL which already has the ability to
dynamically load files and have the browser
recognize them.
TNL-46
I've changed Studio to catch JavaScript errors when rendering xblocks, log the error, but to then continue as normal. This means that the user is still able to interact with the xblock to delete, duplicate etc. This seems reasonable as the xblock is only rendered as a WYSIWYG representation so if it isn't fully interactive that shouldn't be a big problem.
This commit implements STUD-1490, allowing creation of components
on the container page. It also enables the delete and duplicate
buttons now that new content can be created that would benefit.
Note that it also creates shared functionality for adding components,
and refactors the unit page to use it too.
STUD-1465
Changed the XBlock rendering logic to use promises to track asynchronous tasks.
Each dependency is then only loaded once the previous one has completed, and the
XBlock initialization only happens once all dependencies are loaded. This gives
XBlocks the same semantics in Studio as they get when shown directly on a page.
This is the changes for STUD-1244, which introduces the ability for Studio to display
arbitrarily nested xblocks. In this change, a new container page is introduced which can
display nested xblocks. In particular, the xblock type of 'vertical' is special cased
to be shown inline as a collapsible section. The unit page is mostly unchanged, except
that container xblock's are shown as a link to their container page, rather than being
shown inline.
