mirror of
https://github.com/moodle/moodle.git
synced 2025-08-11 03:46:42 +02:00
0a606a2be2
1. Autosave works in some ways just like a normal save. We ultimately call $behaviour->process_save() to do the work, and create a new step to hold the data. 2. However, we come in through a completely different route through the API, starting with separate auto-save methods. This keeps the auto-save changes mostly separate, and so reduced the chance of breaking existing working code. 3. When the time comes to store the auto-save step in the database, we save it using a negative sequence number. This is a clever trick that not only distinguises these steps, but also avoids unique key errors when an auto-save and a real action happen simultaneously. (There are unit tests for these tricky edge cases.) 4. When we load the data back from the database, most of the time the auto-save steps are loaded back as if they were a real save, and so the auto-saved data is used when the question is then rendered. 5. However, before we process another action, we remove the auto-saved step, so it does not appear in the final history. |
||
|---|---|---|
| .. | ||
| adaptive | ||
| adaptivenopenalty | ||
| deferredcbm | ||
| deferredfeedback | ||
| immediatecbm | ||
| immediatefeedback | ||
| informationitem | ||
| interactive | ||
| interactivecountback | ||
| manualgraded | ||
| missing | ||
| behaviourbase.php | ||
| rendererbase.php | ||
| upgrade.txt | ||