...
...
...
...
Devstack development process
- Clone the repo to your devstack/src directory. This directory is generally mounted to be shared with the devstack VM
- `vagrant ssh` to SSH on to the Devstack
- `sudo su edxapp` to log in at the edxapp user
- cd to the src/xblock-drag-and-drop-v2/ directory
- run `pip uninstall xblock-drag-and-drop-v2` to remove the installed version
- run `python setup.py develop`
Feature Overview
Drag and drop v2 XBlock implements a friendly drag-and-drop style problem, where the learner has to drag items to zones on a target image.
...
Studio interface (drag_and_drop_edit.js) contains single function/class DragAndDropEditBlock(runtime, element, params) that follows JS XBlock signature.
...
- DnDv2 test suite heavily relies on integration tests - might be good to replace at least some of those with unit tests (python and JS)
- Take very long time to run entire suite
- No JS unit tests
- JS code coverage is never collected (there are tools for instrumenting selenium to do so, but no one actually investigated this).
- Some tests are fragile (but not flaky) - under certain conditions element to receive a click is not visible in the selenium viewport, which results in an error. All of such tests have `scroll_down` parameter somewhere in the call chain - adjusting the value might be needed when DnDv2 layout changes.
- Code coverage result is probably an over-estimation as integration tests tend to hit a lot of lines, while actually testing a few. Branch coverage might be quite poor.
- Complete lack of logging
- No load tests, but most likely there shouldn't be any problem.
- Trivial tech debt:
- 2 handlers do not use XBlock.json_handler decorator, but still return "application/json"
- Keeping highest available grade is not documented in any student-facing part of the system, so students only can discover it by trial and error; also, this is not in line with CAPA problems
- Significant vertical separation - methods in DragAndDropBlock are not always semantically grouped together.
- Very long and complicated methods (i.e. get_feedback)
- DragAndDropBlock class resembles a God Object a bit - might make sense to start pulling it apart (this is considered and certain options are evaluated now)
- Some methods and properties have to be invoked in certain order (and that order is not explicitly visible) - potential source of bugs:
- Complex frontend code + different libs are used for editor and for student view (VirtualDom vs Handlebars).
- (Arguable) Student view does not use templates at all - as a result everything is constructed via VirtualDom calls - complex and non-intuitive (~500 lines of code building DOM elements)
Student interaction diagrams
| Standard Mode | Assessment Mode |
|---|---|
|
|
