Closed gsidebo closed 6 years ago
I think #2 in the description is most sensibly done in the XBlock
repo. Some rough implementation thoughts:
XBlockAside
. This method would take a block and return a boolean indicating whether or not the aside should decorate that block. Base implementation simply returns True
and can be overridden for any aside that needs to be limited based on some properties of the block.runtime.py
, change applicable_aside_types
/get_asides
to limit the list of asides to those that return True
for the method described above.When you say "this method would take a block" is that a generic XBlock type (not sure if that's the write word) or a specific xBlock locator (again, not sure if that's the right word)?
I believe recognizing Multiple Choice problems is going to require inspecting the Capa block's OLX. But we could still get a lot of value by limiting the aside to the Capa block "type."
Not a blocker either way, I'd just like to know what you're proposing.
Unless I'm mistaken about the execution, the input would be an actual XBlock instance with all its mixins and fields. I believe the OLX could be inspected from this instance
PR opened upstream for XBlock: https://github.com/edx/XBlock/pull/374
My original thinking back when I was designing asides was that this type of functionality would a) be exposed to the course author, and b) be more declarative (like a CSS selector). However, I think for your purposes, where a particular aside specifically only supports a subset of XBlocks, the current strategy makes sense to include as well.
edx/XBlock#374 is now merged. Whats left:
edx-platform
(PR: https://github.com/mitodl/edx-platform/pull/85)XBlockAside
functionality
We don't currently have any logic that limits rapid response functionality to multiple choice problems (which we defined as our MVP). This needs to be accounted for in a couple areas: