|
|
|
For the target release, we need to re-organize GLOBALS used by Moodle a bit. If I'm not forgetting anything they are:
- CFG
- COURSE
- USER
- THEME
The objective should be that every global should contain EXCLUSIVELY its own data, no data belonging to another variable. So all the user (session!) related info should go to USER and all the course related info should go to COURSE.
This'll have at least two benefits:
- Organization. Every variable in its place.
- Caching. CFG can be cached globally (memcached..) and USER can be cached at session level. This are at least two less queries per page.
Ciao :-)
|
|
Description
|
For the target release, we need to re-organize GLOBALS used by Moodle a bit. If I'm not forgetting anything they are:
- CFG
- COURSE
- USER
- THEME
The objective should be that every global should contain EXCLUSIVELY its own data, no data belonging to another variable. So all the user (session!) related info should go to USER and all the course related info should go to COURSE.
This'll have at least two benefits:
- Organization. Every variable in its place.
- Caching. CFG can be cached globally (memcached..) and USER can be cached at session level. This are at least two less queries per page.
Ciao :-) |
Show » |
|
Task
Open
Critical
Globals reorganization...
1. $PAGE exists in some scenarios.
2. $adminroot is "used as" a global, meaning that it's passed as a parameter in function calls. The one example of this I have seen is notice(). While this is not a global variable as such, it could very well be and should probably get the same treatment.