What's needed for an XBlock to create children from XML?

Braden MacDonald

unread,

Feb 5, 2015, 2:35:57 PM2/5/15

to edx-...@googlegroups.com

TL;DR: in Studio, there seems to be no way for an XBlock to instantiate new XBlocks from XML

We are in the process of converting the "mentoring" XBlock to have native XBlock children. Much like the <problem_demo> block in the XBlock SDK, we want the block to be composed of smaller XBlocks such as <question>, <html>, <answer>, etc.

The block currently has a String field, xml_content, which lets course authors edit the XML defining the mentoring block and all of its children, much like the advanced editor of capa problems.

However, while the re-engineered block is now working perfectly in the SDK, it is not yet working in Studio. I can't figure out how the XBlock can ask the runtime to assign its children based on the xml_content.

In our studio_submit() ajax handler, if I try parsing the XML and then calling self.runtime.add_node_as_child(...) on each node found in the XML, it fails because it depends on id_generator.create_definition() which doesn't seem to be implemented. I tried implementing it but it became whack-a-mole where each attempted fix caused a new issue elsewhere.

I also considered breaking the XBlock abstraction and using self.runtime.modulestore.add_child() followed by updating the child's fields with the XML data, but the XBlock API has no way for an instantiated XBlock to set its fields from an XML node - the parse_xml method always attempts to create a new block, which won't work in Studio or the LMS.

For now we would be happy with a way to instantiate XBlock children from XML at runtime even if there is no persistence of the children, though that would be ideal.

Any advice?

Thanks!!

--

Braden MacDonald

@OpenCraft

Andy Armstrong

unread,

Feb 5, 2015, 3:06:54 PM2/5/15

to edx-...@googlegroups.com

Hey Braden,

Can you explain more of your reasoning as to why the XBlock needs to have an XML definition which includes the definitions for all of its children. Having a single XML string that represents all of the children seems to make it very onerous for a Studio author to create such a block. This is especially true if the mentoring XBlock wants to include some of the more complex xblocks as children, such as ORA peer assessments or content experiments.

I would have expected that you would instead create each child as a first class XBlock which you would then edit independently. In Studio this would behave more like the content experiment xblock that allows the user to add any children of their choice to the block. If the user is creating the course by hand in XML, it would also be much simpler for them to edit each child separately, rather than trying to define the children inside a string in the parent block.

Is the problem that the XML needs to define how the layout of the mentoring block works, and so it isn't as straightforward as just having a set of children?

I'd be very happy to discuss this in more detail so just let me know how I can help.

Thanks,

- Andy

--

Andy Armstrong

edX | UI Architect | an...@edx.org

141 Portland Street, 9th floor

Cambridge, MA 02139

http://www.edx.org

Braden MacDonald

unread,

Feb 5, 2015, 4:31:49 PM2/5/15

to edx-...@googlegroups.com

Hi Andy,

Letting the XBlock define its children via XML is by no means a hard requirement, but it seemed like most efficient approach at the time the mentoring block was first designed (but using "light" XBlock-like children instead of real XBlock children), and perhaps still is.

I actually raised similar questions to your in an internal discussion at OpenCraft - here is Xavier's reply verbatim: Using first-class XBlock child editing in Studio "is actually something I'd like to think of in the long term, as editing XML isn't very convenient for the users. Using the Studio editing capabilities to edit the XBlock structure is very tempting - but I also think we are pretty far away from being able to do something intuitive with the current state in Studio. For example, there is no way to create new children within an XBlock, only to display children already contained in an XBlock. Also, I'm not fully convinced this should be Studio's responsibility - it seem like creating children and the interface to do that might differ depending on the XBlock (creating entries in a poll isn't the same as adding points on a map – both could be valid types of children though). It might make more sense control the creation of children from within the XBlock itself, using widget libraries for shared interface elements."

If you want to see an example of the XBlock XML we're talking about, there's one here. As you can see, the children of the mentoring block also have children, and the blocks also sometimes need to reference each other by ID or name.

Thanks!

--

Braden MacDonald

@OpenCraft

Calen Pennington

unread,

Feb 5, 2015, 4:47:59 PM2/5/15

to edx-...@googlegroups.com

My thoughts on this have always been that studio would essentially expose to an XBlock a hook to allow the XBlock to trigger the find-or-create of a new child. So, the XBlock would have control over how, and studio could present an interface for finding existing problems.

Alternately (or additionally), the Studio runtime could expose a method for creating a new xblock of a particular type, and the parent XBlock could call that, modify the fields, call .save(), and then add that blocks usage_key to it's own list of children.

-Cale

Braden MacDonald

unread,

Feb 9, 2015, 3:24:26 PM2/9/15

to edx-...@googlegroups.com

Cale, that sounds good to me. Do you have any further thoughts on what find-or-create would look like? Does it need to be more efficient than a block implementing its own "find" by walking it's .children property with runtime.get_block()? Because a simplistic implementation could work with just the existing child access that already exists, and adding a new "add_child" method that's a thin wrapper around modulestore.create_child().

Also would this be an XBlock service or just a method on the runtime that's only available in Studio?

--

Braden MacDonald

@OpenCraft

Tam Dang Minh

unread,

Aug 25, 2017, 9:55:56 AM8/25/17

to General Open edX discussion, bra...@opencraft.com

Hi Braden,

I am struggling with this thought as well. Did you have any way to strive this idea ?