This is an old revision of the document!
The course elements are structuring primitives dedicated to contents.
In order to give a good unity of form, and to allow learners to clearly identify the educational demand, they allow a fast implementation of the contents, texts and messages. Some of them have added functionalities.
The teacher only cares about the local formatting of his message, without worrying about the visual “integration” of his message.
There are 5 types of course elements with different functionalities:
![]() | ![]() | ![]() | ![]() | ![]() | ![]() | ![]() | ![]() |
---|---|---|---|---|---|---|---|
| | | | | | | |
Travis-ci Continuous integration
Note : Failing status is not necessarily the sign of a non functioning module. It just says that the Moodle code standards check are not full filling. This is a continuous effort of us rewriting the plugin code to get it compliant.
We seriously plan to rewrite fundamentally this module in order to simplify the implementation. the major reason of the code complexity of this module was the inheritance of tricky constraints of Moodle 1.9 architecture for being able to produce the course element content in the course view. This has not been reviewed because we needed at early moodle 2.x stages that the plugin keep entire compatibility with Moodle 1.9 contents.
The pressure to stay full compatible with old storage model is lower now, unless we can provide a good model translator for actual component architecture to new one.
I am sure that the component will gain in maintenability, and will lower risk of technological obsolescence in the future.
What should be great to achieve as workplan:
The global goal of those changes is to make all aspect configuration possible without coding access.
As usual, such a radical change needs a lo of time, and probably budget. At the moment I lack both. So I do not expect short time resolution at the moment, but the road is traced.