As part of the static asset build, JS modules for most built-in XBlocks were
unnecessarily copied from the original locations (under xmodule/js and
common/static/js) to a git-ignored location (under common/static/xmodule), and
then included into the Webpack builld via
common/static/xmodule/webpack.xmodule.config.js.
With this commit, we stop copying the JS modules. Instead, we have
common/static/xmodule/webpack.xmodule.config.js just reference the original
source under xmodule/js and common/static/js.
This lets us us radically simplify the xmodule/static_content.py build script.
It also sets the stage for the next change, in which we will check
webpack.xmodule.config.js into the repository, and delete
xmodule/static_content.py entirely.
common/static/xmodule/webpack.xmodule.config.js before:
module.exports = {
"entry": {
"AboutBlockDisplay": [
"./common/static/xmodule/modules/js/000-b82f6c436159f6bc7ca2513e29e82503.js",
"./common/static/xmodule/modules/js/001-3ed86006526f75d6c844739193a84c11.js",
"./common/static/xmodule/modules/js/002-3918b2d4f383c04fed8227cc9f523d6e.js",
"./common/static/xmodule/modules/js/003-b3206f2283964743c4772b9d72c67d64.js",
"./common/static/xmodule/modules/js/004-274b8109ca3426c2a6fde9ec2c56e969.js",
"./common/static/xmodule/modules/js/005-26caba6f71877f63a7dd4f6796109bf6.js"
],
"AboutBlockEditor": [
"./common/static/xmodule/descriptors/js/000-b82f6c436159f6bc7ca2513e29e82503.js",
"./common/static/xmodule/descriptors/js/001-19c4723cecaa5a5a46b8566b3544e732.js"
],
// etc
}
};
common/static/xmodule/webpack.xmodule.config.js after:
module.exports = {
"entry": {
"AboutBlockDisplay": [
"./xmodule/js/src/xmodule.js",
"./xmodule/js/src/html/display.js",
"./xmodule/js/src/javascript_loader.js",
"./xmodule/js/src/collapsible.js",
"./xmodule/js/src/html/imageModal.js",
"./xmodule/js/common_static/js/vendor/draggabilly.js"
],
"AboutBlockEditor": [
"./xmodule/js/src/xmodule.js",
"./xmodule/js/src/html/edit.js"
],
// etc
}
};
Part of: https://github.com/openedx/edx-platform/issues/32481
This PR addresses the renaming of the contentstore/xblock_services folder to contentstore/xblock_storage_handlers as a follow-up to PR #32282. The renaming is done to prevent naming conflicts with xblock runtime services and to make the purpose of the files more understandable. The file xblock_service.py has been renamed to view_handlers.py to better reflect its functionality.
Justification and Future Refactoring Outlook:
The xblock_storage_handlers folder contains service methods that implement the business logic for view endpoints located in contentstore/views/block.py. It is renamed to xblock_storage_handlers to reflect its responsibility of handling storage-related operations of xblocks, such as creation, retrieval, and deletion.
The view_handlers.py file includes business methods called by the view endpoints. These methods, such as handle_xblock, delete_orphans, etc., interact with the required modulestore methods, handle any errors, and aggregate and serialize data for the response.
The term 'handler' in the context of 'view_handlers.py' represents methods that facilitate business logic for view endpoints. It is critical to note the distinction between these 'handler methods' and the xblock_handler method. The xblock_handler is a view endpoint itself, residing in contentstore/views/block.py, and is well known in this context. Although its name might suggest otherwise, it is not a handler in the sense of the 'handler methods' we've defined in 'view_handlers.py'. To maintain consistency with existing naming conventions, it remains as xblock_handler.
