Conversation
Co-authored-by: Claude <claude@anthropic.com>
ormsbee
left a comment
There was a problem hiding this comment.
@sarina: Some change requests. I haven't actually run through the instructions here myself yet, and probably won't get around to it until mid-week.
@pdpinch: Would you or someone on your team familiar with Asides like to review this? There are places where I'm unsure and wrote that I need to verify things, but if someone on your team knows, their feedback would be most appreciated. Thank you.
| XML child element under its host block, named after the aside's entry point | ||
| name. On import, the runtime reconstitutes the asides automatically. This |
There was a problem hiding this comment.
Note to self: Check this. I thought Asides serialized into the tag itself as namespaced attributes.
| The Studio runtime does not consult this configuration. Asides render | ||
| in Studio author views independently of ``XBlockAsidesConfig``, as soon | ||
| as they are installed and registered. |
There was a problem hiding this comment.
Note to self: Verify this and file a bug if necessary.
There was a problem hiding this comment.
Not a bug, studio has its own model to gate asides.
|
|
||
| Inherited from ``Blocklike``. Override these to customize how the aside is | ||
| read from and written to OLX. The default implementations serialize the | ||
| aside's fields as XML attributes and child elements, identical to the |
| * An aside's data only round-trips through OLX if both the source and | ||
| destination platforms have the same aside installed under the same | ||
| entry point name. |
pdpinch
left a comment
There was a problem hiding this comment.
Pretty impressive, especially creating two different example Asides, one for the how-to and one for the quickstart. I left some notes.
I'm going to ask a couple of the devs who have worked with Asides to review this as well.
| An XBlock aside is a class that injects content into the rendered views of | ||
| existing XBlocks without modifying those XBlocks. Asides let you add behavior, | ||
| data, and UI elements to many XBlock instances at once, across XBlock types you | ||
| do not own, while preserving the host XBlock's code, fields, and Open Learning |
There was a problem hiding this comment.
What does this mean, "across XBlock types you do not own" ?
There was a problem hiding this comment.
Claude describes what it meant:
By "XBlock types you do not own," I meant XBlocks whose source code you don't maintain — typically core platform blocks like problem and video (owned by the edx-platform team), or third-party blocks like ORA2, or blocks maintained by another organization. If you wanted to enhance one of those, your non-aside options are: fork it (and maintain a parallel copy), upstream a PR (slow, narrow design space, may be rejected), or wrap it in a replacement block (forces every existing course to migrate). Asides give you a fourth option: attach behavior from your own installable package, leaving the upstream code untouched.
That said — if you're asking, the phrasing wasn't self-explanatory, which is its own signal. Some options to make it clearer:
Option A (minimal — define the term in place):
across XBlock types whose source you do not maintain (for example, the platform's built-in
problemandvideoblocks, or third-party blocks installed as separate packages)
Option B (recast — drop the ownership framing, lead with the practical consequence):
Asides let you add behavior, data, and UI elements to many XBlock instances at once — including instances of XBlock types maintained by other teams or installed as third-party packages — while preserving the host XBlock's code, fields, and Open Learning XML (OLX) representation.
Option C (cut it):
Asides let you add behavior, data, and UI elements to many XBlock instances at once, while preserving the host XBlock's code, fields, and OLX representation.
The "without modifying those XBlocks" earlier in the same paragraph already implies this, so cutting the phrase entirely is defensible. The rest of the concept doc, particularly the "The Problem Asides Solve" section, makes the fork-vs-replace-vs-aside trade-off explicit.
Do any of these options feel correct, and worth applying?
| XML child element under its host block, named after the aside's entry point | ||
| name. On import, the runtime reconstitutes the asides automatically. This |
|
|
||
| The Studio author view for an aside is rendered by the legacy course | ||
| authoring frontend. The current Course Authoring micro-frontend has no | ||
| defined location to display aside author UI. If your project depends on the |
There was a problem hiding this comment.
This is old news. The authoring view in the MFE works just fine, although it is different from the legacy studio UI.
| with the export process. Some XBlocks, including ORA2, do not preserve | ||
| aside data through their export and import paths. If your aside must | ||
| survive a course export and re-import on a course that uses one of these | ||
| blocks, test the round trip end to end before depending on it. |
There was a problem hiding this comment.
@arslanashraf7 or @asadali145 do you recall the details of this?
Co-authored-by: David Ormsbee <dave@axim.org> Co-authored-by: Peter Pinch <pdpinch+github@hawklake.com>
|
Belatedly, I'm 100% realizing these docs should live in https://github.com/openedx/XBlock/tree/master/docs not here. However, I think it'd be best since we're already mid-review to continue to review here, and when we're satisfied I'll close this PR and open it appropriately over in the XBlock repo for final review. |
| No Authoring Story in the Course Authoring MFE | ||
| ============================================== | ||
|
|
||
| The Studio author view for an Aside is rendered by the legacy course | ||
| authoring frontend. The current Authoring micro-frontend has no | ||
| defined location to display Aside author UI. If your project depends on the | ||
| new MFE for authoring, plan to render the Aside's author UI through a | ||
| different mechanism, or accept that authors will use the legacy Studio for | ||
| this part of the workflow. |
There was a problem hiding this comment.
There are 2 views, AUTHOR_VIEW and STUDIO_VIEW.
Previously, we used STUDIO_VIEW to display any aside field, like enable/disable checkbox, etc., and it was displayed in the editor. By editor, I mean the edit view that opens when we click the edit button of an XBlock in Studio. There used to be a settings tab in that editor. This is not available in the authoring MFE.
Alternatively, we shifted to AUTHOR_VIEW and used it to display the fields on the unit page in authoring MFE, and this works fine.
In ol_openedx_chat aside, we have an author_view, and it displays the checkbox field in the unit view like:
We should note that we are using an XBlock handler to save the state of this checkbox. XBlock handler is called from JS when state of this checkbox changes.
| with the export process. Some XBlocks, including ORA2, do not preserve | ||
| aside data through their export and import paths. If your aside must | ||
| survive a course export and re-import on a course that uses one of these | ||
| blocks, test the round trip end to end before depending on it. |
There was a problem hiding this comment.
@ormsbee If I understand it correctly, this is related to openedx/openedx-platform#36576.
| .. _rapid-response-xblock: https://github.com/mitodl/open-edx-plugins/tree/main/src/rapid_response_xblock | ||
| .. _ol-openedx-chat: https://github.com/mitodl/open-edx-plugins/tree/main/src/ol_openedx_chat | ||
| .. _xblock-sdk: https://github.com/openedx/xblock-sdk |
There was a problem hiding this comment.
FYI, that StructuredTagsAside was helpful for us.
| The Studio runtime does not consult this model. Asides will render in | ||
| Studio author views as soon as they are installed, independently of | ||
| whether ``XBlockAsidesConfig`` is enabled. |
There was a problem hiding this comment.
This is partially correct, for studio, there is similar model in studio admin at http://studio.local.openedx.io:8001/admin/xblock_config/studioconfig/ that gates the asides.
| The Studio runtime does not consult this configuration. Asides render | ||
| in Studio author views independently of ``XBlockAsidesConfig``, as soon | ||
| as they are installed and registered. |
There was a problem hiding this comment.
As mentioned in Quickstart, Studio has its own model http://studio.local.openedx.io:8001/admin/xblock_config/studioconfig/. We need to enable it to enable the aside author view.
| @XBlockAside.aside_for("studio_view") | ||
| def studio_view_aside(self, block, context=None): | ||
| """Render the author-side toggle UI in Studio.""" | ||
| checked = "checked" if self.enabled else "" | ||
| html = ( | ||
| f'<label><input type="checkbox" {checked} ' | ||
| f'class="feedback-badge-toggle"> Show feedback link</label>' | ||
| ) | ||
| return Fragment(html) |
There was a problem hiding this comment.
Changing the state of this checkbox won't save the setting. We will need to implement a handler and write custom JS to call the handler when the state of this field changes to save the setting. I have mentioned this in my other comment in about_xblock_asides.rst
| ``"about course_info static_tab"``). The Studio runtime does not | ||
| apply this gate. See :ref:`Add an XBlock Aside` for the | ||
| administrative steps to enable the configuration. |
There was a problem hiding this comment.
As mentioned already, studio also gates the asides.
| tutor mounts add /path/to/feedback_badge_aside | ||
| tutor dev launch |
There was a problem hiding this comment.
I couldn't test this with mounts. I'll give it another go later today.
Claude prompt log for this PR