Class: course_modinfo  - X-Ref

Information about a course that is cached in the course table 'modinfo' field (and then in
memory) in order to reduce the need for other database queries.

This includes information about the course-modules and the sections on the course. It can also
include dynamic data that has been updated for the current user.

Use {@link get_fast_modinfo()} to retrieve the instance of the object for particular course
and particular user.

Class: cm_info  - X-Ref

Data about a single module on a course. This contains most of the fields in the course_modules
table, plus additional data when required.

The object can be accessed by core or any plugin (i.e. course format, block, filter, etc.) as
get_fast_modinfo($courseorid)->cms[$coursemoduleid]
or
get_fast_modinfo($courseorid)->instances[$moduletype][$instanceid]

There are three stages when activity module can add/modify data in this object:

<b>Stage 1 - during building the cache.</b>
Allows to add to the course cache static user-independent information about the module.
Modules should try to include only absolutely necessary information that may be required
when displaying course view page. The information is stored in application-level cache
and reset when {@link rebuild_course_cache()} is called or cache is purged by admin.

Modules can implement callback XXX_get_coursemodule_info() returning instance of object
{@link cached_cm_info}

<b>Stage 2 - dynamic data.</b>
Dynamic data is user-dependent, it is stored in request-level cache. To reset this cache
{@link get_fast_modinfo()} with $reset argument may be called.

Dynamic data is obtained when any of the following properties/methods is requested:
- {@link cm_info::$url}
- {@link cm_info::$name}
- {@link cm_info::$onclick}
- {@link cm_info::get_icon_url()}
- {@link cm_info::$uservisible}
- {@link cm_info::$available}
- {@link cm_info::$availableinfo}
- plus any of the properties listed in Stage 3.

Modules can implement callback <b>XXX_cm_info_dynamic()</b> and inside this callback they
are allowed to use any of the following set methods:
- {@link cm_info::set_available()}
- {@link cm_info::set_name()}
- {@link cm_info::set_no_view_link()}
- {@link cm_info::set_user_visible()}
- {@link cm_info::set_on_click()}
- {@link cm_info::set_icon_url()}
- {@link cm_info::override_customdata()}
Any methods affecting view elements can also be set in this callback.

<b>Stage 3 (view data).</b>
Also user-dependend data stored in request-level cache. Second stage is created
because populating the view data can be expensive as it may access much more
Moodle APIs such as filters, user information, output renderers and we
don't want to request it until necessary.
View data is obtained when any of the following properties/methods is requested:
- {@link cm_info::$afterediticons}
- {@link cm_info::$content}
- {@link cm_info::get_formatted_content()}
- {@link cm_info::$extraclasses}
- {@link cm_info::$afterlink}

Modules can implement callback <b>XXX_cm_info_view()</b> and inside this callback they
are allowed to use any of the following set methods:
- {@link cm_info::set_after_edit_icons()}
- {@link cm_info::set_after_link()}
- {@link cm_info::set_content()}
- {@link cm_info::set_extra_classes()}

Class: cached_cm_info  - X-Ref

Class that is the return value for the _get_coursemodule_info module API function.

Note: For backward compatibility, you can also return a stdclass object from that function.
The difference is that the stdclass object may contain an 'extra' field (deprecated,
use extraclasses and onclick instead). The stdclass object may not contain
the new fields defined here (content, extraclasses, customdata).

Class: section_info  - X-Ref

Data about a single section on a course. This contains the fields from the
course_sections table, plus additional data when required.