Talk:Module visibility and display
From MoodleDocs
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.
