Add logic to parse XBlock's XML with the pointer tag correctly.

[ttqureshi]

Currently parse_xml function in xblock/core.py doesn't support the implementation to parse the pointer tags within an XBlock's XML file. It instantiates the XBlock without picking fields data (and other metadata, if any) if there is a pointer tag.

Example XML with pointer tag

<vertical display_name="LTI">
  <lti url_name="lti"/>
</vertical>

Why need it?

We are extracting BuiltIn XBlocks from edx-platform, in order for the extracted XBlocks to work properly we want this pointer tag logic to be implemented in xblock/core.py. This will prevent breaking any functionality, ensuring that XBlock's definition is loaded correctly.

Here's the reference from Demo course, which was exported from Studio as recently as Redwood:

• within a vertical LTI block pointer tag
• pointing to the LTI Block definition here.

[ttqureshi]

FYI @kdmccormick

cc: @farhan @salman2013 @irtazaakram

[kdmccormick]

TY. Out on vacation currently but I will add some notes when I'm back on Friday.

[kdmccormick]

I have created this ticket for the overall bug investigation:

• When and why did pointer syntax break for external blocks? edx-platform#36390

We can keep this issue (xblock/823) focused on fixing the immediate bug, and use edx-platform/36390 for the big-picture investigation of what happened.

[kdmccormick]

There is one big-picture thing we need to worry about for this ticket:

In order to keep Teak course exports compatible with the broken releases (which are most likely Redwood and Sumac), we should continue to export the currently-external blocks using inline syntax, even though we will restore the ability to import them with pointer syntax. I think we could do this by adding a new class variable to XBlock called export_with_pointer_tag, defaulting to False. The currently-built-in blocks and their extracted counterparts can override this variable to True. The export process can look at the variable to determine whether to export that block using inline or pointer syntax.

For example: Because drag-and-drop-v2 fails to import with pointer syntax in Redwood and Sumac, we should make sure to export it via inline syntax going forward, so that if an author exports drag-and-drop-v2 from Teak, it will load correctly into Redwood and Sumac.

Another example: Because word_cloud imports OK with pointer syntax in all releases, we can export it using pointer syntax even after we extract it, because it pointer syntax will work fine for it in Redwood and Sumac. So, we would set export_with_pointer_syntax = True in its class definition.

Alternatively, if we can find out when and why pointer syntax stopped working and backport a bugfix to all affected releases, then we can instead return to the behavior of always exporting every block with pointer syntax.

[ttqureshi]

Thanks @kdmccormick for the introspective look into the issue.
I will be starting to work on this issue (XBlock/823) as it is blocking the LTI XBlock Extraction.

[bradenmacdonald]

We have previously made the decision to move away from XBlocks having children, and move toward a system where we use Containers for hierarchy above the Component level. So I'm a little bit hesitant to add this logic (which is strictly related to parsing/encoding children) into XBlock core.

When you see something like the example linked above:

<vertical display_name="Code Grading">
   ...
  <lti url_name="8e71d278e94f4913bc564cc6141fde53"/>
   ...
</vertical>

It's true that we could put logic into the XBlock core so that the LTI block can parse that itself, but it's equally possible (and I would argue, better) to shift this up one level and have the vertical block in this case realize that the child is a pointer node and load the full definition before telling the LTI block to parse it.

In fact, I don't think we need to make any XBlocks aware of pointer nodes. With the example code here, when the vertical block encounters <lti url_name="..." />, it should call runtime.add_node_as_child(block, child). Why can't we just make it so that that runtime function understands pointer nodes and substitutes in the full XML before calling the child (LTI in this example) to parse_xml ?

[ttqureshi]

Thanks @bradenmacdonald for the input.

but it's equally possible (and I would argue, better) to shift this up one level and have the vertical block in this case realize that the child is a pointer node and load the full definition before telling the LTI block to parse it.

After brainstorming and connecting a few dots, I think that we might need to define parse_xml method inside the VerticalBlock. This parse_xml method will:

• load the vertical block definition from the file
• check if the child node is a pointer node then load it's full definition and
• return the block

Please share your thoughts on this. Would this serve the purpose without touching the xblock core functionality?