In the libraries implementation, we use a Content representation of the block.xml to provide the OLX that renders a component-level XBlock. We definitely want to have this file, because it's the thing we're going to export when the XBlock gets DEPR and goes away twelve years from now. But there are going to be other situations where XBlocks want data from multiple source files. The HTMLBlock is kinda hacked to use CDATA for libraries right now, but it usually defines an HTML file in Modulestore. Looking forward more, it would be nice if we could modify ProblemBlock to keep Python source files separate from the XML, but still read them in for the purposes of the XBlock rendering in an optimized way that just did one select instead of each XBlock making n-queries for all the pieces it needs.
This does not block the Redwood preview release, but we should strongly consider it for Sumac.
In the libraries implementation, we use a
Contentrepresentation of theblock.xmlto provide the OLX that renders a component-level XBlock. We definitely want to have this file, because it's the thing we're going to export when the XBlock gets DEPR and goes away twelve years from now. But there are going to be other situations where XBlocks want data from multiple source files. TheHTMLBlockis kinda hacked to use CDATA for libraries right now, but it usually defines an HTML file in Modulestore. Looking forward more, it would be nice if we could modify ProblemBlock to keep Python source files separate from the XML, but still read them in for the purposes of the XBlock rendering in an optimized way that just did one select instead of each XBlock making n-queries for all the pieces it needs.This does not block the Redwood preview release, but we should strongly consider it for Sumac.