Development talk:Module visibility and display: Difference between revisions
No edit summary |
No edit summary |
||
Line 8: | Line 8: | ||
------ | ------ | ||
+1 from me.--[[User:Tim Hunt|Tim Hunt]] 18:39, 15 December 2010 (UTC) | +1 from me.--[[User:Tim Hunt|Tim Hunt]] 18:39, 15 December 2010 (UTC) | ||
==A few comments== | |||
# the modinfo could be a class with extra methods for the new stuff - instead of precalculating everything we could do the extra work only when necessary, it should be 100% compatible with current code and it could actually detect some parameter problems; another reason is there is no proper phpdocs which prevents autocomplete from working in IDEs | |||
# icon and iconcomponent are supposed to be the new api, the mod/mymodule/iconname hack should be deprecated instead | |||
# at the same time we should fix the known perf problems with the modinfo caching | |||
Alternative proposal: | |||
* create new interface module_info which is backwards compatible with old $cminfo, add hidden setting which specifies which class to use | |||
* keep get_fast_modinfo() and make it return array of instances with module_info interface | |||
* either use plugin_supports() for finding out if plugin contains view.php (false means no url, true default) - external urls and nonstandard urls are supposed to be implemented via view.php redirects such as in the mod/url | |||
* or simply check if mod/xx/view.php exists (did we ever consider this solution?) | |||
* all course page specific data could be initialised/computed only when necessary | |||
Benefits could be a bit better performance, smaller course->modinfo and finally all the customisation could be done via modification/replacement of one class only. |
Revision as of 16:56, 19 December 2010
UCLA is very excited about this feature. Currently we are using a patch that we call public/private (http://moodle.org/mod/data/view.php?d=13&rid=2768) to accomplish this functionality.
This proposed feature would remove the need to maintain our customized code.
Additionally, allowing the developers to add custom editing icons next to resources/activities without modifying core moodle is an excellent idea! --Nick Thompson 17:37, 15 December 2010 (UTC)
+1 from me.--Tim Hunt 18:39, 15 December 2010 (UTC)
A few comments
- the modinfo could be a class with extra methods for the new stuff - instead of precalculating everything we could do the extra work only when necessary, it should be 100% compatible with current code and it could actually detect some parameter problems; another reason is there is no proper phpdocs which prevents autocomplete from working in IDEs
- icon and iconcomponent are supposed to be the new api, the mod/mymodule/iconname hack should be deprecated instead
- at the same time we should fix the known perf problems with the modinfo caching
Alternative proposal:
- create new interface module_info which is backwards compatible with old $cminfo, add hidden setting which specifies which class to use
- keep get_fast_modinfo() and make it return array of instances with module_info interface
- either use plugin_supports() for finding out if plugin contains view.php (false means no url, true default) - external urls and nonstandard urls are supposed to be implemented via view.php redirects such as in the mod/url
- or simply check if mod/xx/view.php exists (did we ever consider this solution?)
- all course page specific data could be initialised/computed only when necessary
Benefits could be a bit better performance, smaller course->modinfo and finally all the customisation could be done via modification/replacement of one class only.