openedx.core.lib.xblock_serializer package#
Submodules#
openedx.core.lib.xblock_serializer.api module#
Public python API for serializing XBlocks to OLX
- openedx.core.lib.xblock_serializer.api.serialize_modulestore_block_for_openedx_content(block)#
- This class will serialize an XBlock, producing:
A new definition ID for use in openedx_content
an XML string defining the XBlock and referencing the IDs of its children using <xblock-include /> syntax (which doesn’t actually contain the OLX of its children, just refers to them, so you have to separately serialize them.)
a list of any static files required by the XBlock and their URL
TODO: We should deprecate this in favor of a new openedx_content implementation. We’ve left it as-is for now partly because there are bigger questions that we have around how we should rewrite this (e.g. are we going to remove <xblock-include>?).
- openedx.core.lib.xblock_serializer.api.serialize_xblock_to_olx(block)#
- This class will serialize an XBlock, producing:
an XML string defining the XBlock and all of its children (inline)
a list of any static files required by the XBlock and their URL
This calls XBlockSerializer with all default options. To actually tweak the output, instantiate XBlockSerializer directly.
openedx.core.lib.xblock_serializer.block_serializer module#
Code for serializing a modulestore XBlock to OLX.
- class openedx.core.lib.xblock_serializer.block_serializer.XBlockSerializer(block, write_url_name=True, fetch_asset_data=False, write_copied_from=True)#
Bases:
objectA class that can serialize an XBlock to OLX.
- olx_node: Element#
- olx_str: str#
- static_files: list[StaticFile]#
- tags: Dict[str, Dict[int, List[str]]]#
openedx.core.lib.xblock_serializer.data module#
Simple data structures used for XBlock serialization
openedx.core.lib.xblock_serializer.test_api module#
openedx.core.lib.xblock_serializer.test_utils module#
openedx.core.lib.xblock_serializer.utils module#
Helper functions for XBlock serialization
- openedx.core.lib.xblock_serializer.utils.collect_assets_from_text(text, course_id, include_content=False)#
Yield dicts of asset content and path from static asset paths found in the given text. Make sure to have replaced the URLs with rewrite_absolute_static_urls first. If include_content is True, the result will include a contentstore StaticContent file object which wraps the actual binary content of the file.
- openedx.core.lib.xblock_serializer.utils.get_asset_content_from_path(course_key, asset_path)#
Locate the given asset content, load it into memory, and return it. Returns None if the asset is not found.
- openedx.core.lib.xblock_serializer.utils.get_js_input_files_if_using(olx: str, course_id: CourseKey) [<class 'openedx.core.lib.xblock_serializer.data.StaticFile'>]#
When a problem uses JSInput and references an html file uploaded to the course (i.e. uses /static/), all the other related static asset files that it depends on should also be included.
- openedx.core.lib.xblock_serializer.utils.get_python_lib_zip_if_using(olx: str, course_id: CourseKey) StaticFile | None#
When python_lib is in use, capa problems that contain python code should be assumed to depend on it.
Note: for any given problem that uses python, there is no way to tell if it actually uses any imports from python_lib.zip because the imports could be named anything. So we just have to assume that any python problems may be using python_lib.zip
- openedx.core.lib.xblock_serializer.utils.openedx_core_def_key_from_modulestore_usage_key(usage_key)#
In modulestore, the “definition key” is a MongoDB ObjectID kept in split’s definitions table, which theoretically allows the same block to be used in many places (each with a unique usage key). However, that functionality is not exposed in Studio (other than via content libraries). So when we import into the OeX core content API, we assume that each usage is unique, don’t generate a usage key, and create a new “definition key” from the original usage key. So modulestore usage key
block-v1:A+B+C+type@html+block@introduction
- will become openedx_content definition key
html/introduction
- openedx.core.lib.xblock_serializer.utils.override_export_fs(block)#
Hack that makes some legacy XBlocks which inherit XmlMixin.add_xml_to_node instead of the usual XmlSerialization.add_xml_to_node serializable to a string. This is needed for the OLX export API.
Originally, add_xml_to_node was XModuleDescriptor’s method and was migrated to XmlMixin as part of the content core platform refactoring. It differs from XmlSerialization.add_xml_to_node in that it relies on XmlMixin.export_to_file (or CustomTagBlock.export_to_file) method to control whether a block has to be exported as two files (one .olx pointing to one .xml) file, or a single XML node.
For the legacy blocks (AnnotatableBlock for instance) export_to_file returns True by default. The only exception is CustomTagBlock, for which this method was originally developed, as customtags don’t have to be exported as separate files.
This method temporarily replaces a block’s runtime’s export_fs system with an in-memory filesystem. Also, it abuses the XmlMixin.export_to_file API to prevent the XBlock export code from exporting each block as two files (one .olx pointing to one .xml file).
Although XModuleDescriptor has been removed a long time ago, we have to keep this hack untill the legacy add_xml_to_node implementation is removed in favor of XmlSerialization.add_xml_to_node, which itself is a hard task involving refactoring of CourseExportManager.
- openedx.core.lib.xblock_serializer.utils.rewrite_absolute_static_urls(text, course_id)#
- Convert absolute URLs like
- to the proper
/static/SCI_1.2_Image_.png
format for consistency and portability.
