Competency API - Revision history

Mudrd8mz: Text replacement - "`" to ""`


2021-07-14T13:39:26Z
Text replacement - "<code php>" to "<syntaxhighlight lang="php">"

				
				
				
				
				
				← Older revision
				Revision as of 13:39, 14 July 2021
				
Line 43:
Line 43:
Then indicate to core what class to use by defining the config variable <syntaxhighlight lang="php">$CFG->core_competency_url_resolver</syntaxhighlight>. Then indicate to core what class to use by defining the config variable <syntaxhighlight lang="php">$CFG->core_competency_url_resolver</syntaxhighlight>.



<code php> <syntaxhighlight lang="php">
$CFG->core_competency_url_resolver = '\\your_namespace\\your_class'; $CFG->core_competency_url_resolver = '\\your_namespace\\your_class';
</syntaxhighlight> </syntaxhighlight>



Mudrd8mz: Text replacement - "class="nicetable"" to "class="wikitable""
2021-07-14T13:23:04Z
Text replacement - "class="nicetable"" to "class="wikitable""

				
				
				
				
				
				← Older revision
				Revision as of 13:23, 14 July 2021
				
Line 57:
Line 57:
Here is a non-exaustive list of the persistents: Here is a non-exaustive list of the persistents:



{| class="nicetable" {| class="wikitable"
|- |-
| competency | competency



Mudrd8mz: Text replacement - "" to ""

2021-07-14T13:05:46Z
Text replacement - "<code>" to "<syntaxhighlight lang="php">"

				
				
				
				
				
				← Older revision
				Revision as of 13:05, 14 July 2021
				
Line 1:
Line 1:
{{Moodle 3.1}} {{Moodle 3.1}}
The competency API lives in the subsystem ''competency'', namespaced <code>\core_competency\</syntaxhighlight> and located in the root folder ''competency''. The competency API lives in the subsystem ''competency'', namespaced <syntaxhighlight lang="php">\core_competency\</syntaxhighlight> and located in the root folder ''competency''.



==Mental Models== ==Mental Models==
Line 17:
Line 17:
==External API== ==External API==



[https://git.moodle.org/gw?p=moodle.git;a=blob;f=competency/classes/external.php External functions] are all located in <code>\core_competency\external</syntaxhighlight>, mostly as a proxy to the public API. [https://git.moodle.org/gw?p=moodle.git;a=blob;f=competency/classes/external.php External functions] are all located in <syntaxhighlight lang="php">\core_competency\external</syntaxhighlight>, mostly as a proxy to the public API.



==Evidence== ==Evidence==
Line 25:
Line 25:
===Custom evidence=== ===Custom evidence===



Developers wanting to record evidence for actions that are not covered by the standard API must use <code>\core_competency\api::add_evidence()</syntaxhighlight>. Note that this method does not perform any capability checks as it is expected to be called as the result of another action which has been authorised. Evidence must not be recorded directly, they always are the result of something else. For that reason there is not any external function to add a piece of evidence. Developers wanting to record evidence for actions that are not covered by the standard API must use <syntaxhighlight lang="php">\core_competency\api::add_evidence()</syntaxhighlight>. Note that this method does not perform any capability checks as it is expected to be called as the result of another action which has been authorised. Evidence must not be recorded directly, they always are the result of something else. For that reason there is not any external function to add a piece of evidence.



==Frontend== ==Frontend==



The competency API comes without any frontend, though Moodle core ships with the admin tool <code>tool_lp</syntaxhighlight> which is acting as the default frontend for competencies. It includes templates, javascript (AMD modules) and some additional external functions. It was built split from the backend to easily allow the support for other frontends. The competency API comes without any frontend, though Moodle core ships with the admin tool <syntaxhighlight lang="php">tool_lp</syntaxhighlight> which is acting as the default frontend for competencies. It includes templates, javascript (AMD modules) and some additional external functions. It was built split from the backend to easily allow the support for other frontends.



===URL resolver=== ===URL resolver===
Line 35:
Line 35:
As some of the core APIs require a knowledge of the resource URLs, we introduced the concept of a URL resolver. The URL resolver is used to determine the location of a resource from core, without forcing the default frontend to be used. As some of the core APIs require a knowledge of the resource URLs, we introduced the concept of a URL resolver. The URL resolver is used to determine the location of a resource from core, without forcing the default frontend to be used.



When referring to a resource from ''core'', use the corresponding <code>\core_competency\url::my_ressource_name()</syntaxhighlight> method. Note that it is acceptable for a plugin to directly link to resource frontends within itself without using the resolver. When referring to a resource from ''core'', use the corresponding <syntaxhighlight lang="php">\core_competency\url::my_ressource_name()</syntaxhighlight> method. Note that it is acceptable for a plugin to directly link to resource frontends within itself without using the resolver.



====Defining new URLs==== ====Defining new URLs====
Line 41:
Line 41:
Create a class and implement each routing method defined in [https://git.moodle.org/gw?p=moodle.git;a=blob;f=competency/classes/url.php \core_competency\url], though they should not be static, take [https://git.moodle.org/gw?p=moodle.git;a=blob;f=admin/tool/lp/classes/url_resolver.php \tool_lp\url_resolver] as a base or an example. Create a class and implement each routing method defined in [https://git.moodle.org/gw?p=moodle.git;a=blob;f=competency/classes/url.php \core_competency\url], though they should not be static, take [https://git.moodle.org/gw?p=moodle.git;a=blob;f=admin/tool/lp/classes/url_resolver.php \tool_lp\url_resolver] as a base or an example.



Then indicate to core what class to use by defining the config variable <code>$CFG->core_competency_url_resolver</syntaxhighlight>. Then indicate to core what class to use by defining the config variable <syntaxhighlight lang="php">$CFG->core_competency_url_resolver</syntaxhighlight>.



<code php> <code php>
Line 51:
Line 51:
===Persistents, or Models=== ===Persistents, or Models===



The class <code>\core_competency\persistent</syntaxhighlight> represents an object in the database. It is typically what is called a model in general. It contains the list of fields present in the database table, as well as their <code>PARAM_*</syntaxhighlight> types. Basic validation of the param types is automatically performed prior to any database write operation. Additional validation can also be added by developers. In essence, the persistent knows everything about its data and when it is valid or not. Persistents are able to CRUD themselves in the database. They are also the right place to perform complex queries which join multiple persistents together. The class <syntaxhighlight lang="php">\core_competency\persistent</syntaxhighlight> represents an object in the database. It is typically what is called a model in general. It contains the list of fields present in the database table, as well as their <syntaxhighlight lang="php">PARAM_*</syntaxhighlight> types. Basic validation of the param types is automatically performed prior to any database write operation. Additional validation can also be added by developers. In essence, the persistent knows everything about its data and when it is valid or not. Persistents are able to CRUD themselves in the database. They are also the right place to perform complex queries which join multiple persistents together.



There is never any access control performed within the persistent! However, the competency API is oriented towards model-based Access Control List (ACL), therefore some of the persistents contain helper ACL methods (<code>boolean function can_do_the_thing();</syntaxhighlight>). The main benefit of adding ACL methods to the persistent is to avoid repeating the capability names all over the place, and thus reducing code complexity and human errors. There is never any access control performed within the persistent! However, the competency API is oriented towards model-based Access Control List (ACL), therefore some of the persistents contain helper ACL methods (<syntaxhighlight lang="php">boolean function can_do_the_thing();</syntaxhighlight>). The main benefit of adding ACL methods to the persistent is to avoid repeating the capability names all over the place, and thus reducing code complexity and human errors.



Here is a non-exaustive list of the persistents: Here is a non-exaustive list of the persistents:
Line 126:
Line 126:
Exporters can also define ''related'' objects. When specified those must be set prior to exporting the data, mainly to improve performance. At this stage they may be a bit weak and difficult to work with as adding ''related'' objects to an existing exporter will require all usage of this exporter to be updated. We have raised an issue to try to improve their design: MDL-53052. Exporters can also define ''related'' objects. When specified those must be set prior to exporting the data, mainly to improve performance. At this stage they may be a bit weak and difficult to work with as adding ''related'' objects to an existing exporter will require all usage of this exporter to be updated. We have raised an issue to try to improve their design: MDL-53052.



Exporters have come in very handy when we had to add new properties to persistents, or to export new properties from an existing object. They greatly simplify the maintainability of external functions and <code>templatable::export_for_template()</syntaxhighlight>. Exporters have come in very handy when we had to add new properties to persistents, or to export new properties from an existing object. They greatly simplify the maintainability of external functions and <syntaxhighlight lang="php">templatable::export_for_template()</syntaxhighlight>.



====Formatting, filters, context, etc...==== ====Formatting, filters, context, etc...====



During export, the exporters will take care of formatting the text fields to be ready for output. This means that you do not need to worry about <code>format_string()</syntaxhighlight> and <code>format_text()</syntaxhighlight>. The filters, sanitization rules, etc... will automatically be applied. The exporter will use the related object <code>context</syntaxhighlight> to determine the context of the strings. During export, the exporters will take care of formatting the text fields to be ready for output. This means that you do not need to worry about <syntaxhighlight lang="php">format_string()</syntaxhighlight> and <syntaxhighlight lang="php">format_text()</syntaxhighlight>. The filters, sanitization rules, etc... will automatically be applied. The exporter will use the related object <syntaxhighlight lang="php">context</syntaxhighlight> to determine the context of the strings.



The function <code>format_text()</syntaxhighlight> is applied to properties of type <code>PARAM_RAW</syntaxhighlight> when another property with the same name ending with ''format'' is also present. For instance, a <code>PARAM_RAW</syntaxhighlight> property named ''description'' will be formatted when another property named ''descriptionformat'' is present. The function <code>format_string()</syntaxhighlight> is applied to properties of type <code>PARAM_TEXT</syntaxhighlight>. The function <syntaxhighlight lang="php">format_text()</syntaxhighlight> is applied to properties of type <syntaxhighlight lang="php">PARAM_RAW</syntaxhighlight> when another property with the same name ending with ''format'' is also present. For instance, a <syntaxhighlight lang="php">PARAM_RAW</syntaxhighlight> property named ''description'' will be formatted when another property named ''descriptionformat'' is present. The function <syntaxhighlight lang="php">format_string()</syntaxhighlight> is applied to properties of type <syntaxhighlight lang="php">PARAM_TEXT</syntaxhighlight>.



It is important to note that after formatting the values can contain HTML and will therefore have to be treated as <code>PARAM_RAW</syntaxhighlight>. It is important to note that after formatting the values can contain HTML and will therefore have to be treated as <syntaxhighlight lang="php">PARAM_RAW</syntaxhighlight>.



Mudrd8mz: Text replacement - "" to ""
2021-07-14T13:03:54Z
Text replacement - "</code>" to "</syntaxhighlight>"

				
				
				
				
				
				← Older revision
				Revision as of 13:03, 14 July 2021
				
Line 1:
Line 1:
{{Moodle 3.1}} {{Moodle 3.1}}
The competency API lives in the subsystem ''competency'', namespaced <code>\core_competency\</code> and located in the root folder ''competency''. The competency API lives in the subsystem ''competency'', namespaced <code>\core_competency\</syntaxhighlight> and located in the root folder ''competency''.



==Mental Models== ==Mental Models==
Line 17:
Line 17:
==External API== ==External API==



[https://git.moodle.org/gw?p=moodle.git;a=blob;f=competency/classes/external.php External functions] are all located in <code>\core_competency\external</code>, mostly as a proxy to the public API. [https://git.moodle.org/gw?p=moodle.git;a=blob;f=competency/classes/external.php External functions] are all located in <code>\core_competency\external</syntaxhighlight>, mostly as a proxy to the public API.



==Evidence== ==Evidence==
Line 25:
Line 25:
===Custom evidence=== ===Custom evidence===



Developers wanting to record evidence for actions that are not covered by the standard API must use <code>\core_competency\api::add_evidence()</code>. Note that this method does not perform any capability checks as it is expected to be called as the result of another action which has been authorised. Evidence must not be recorded directly, they always are the result of something else. For that reason there is not any external function to add a piece of evidence. Developers wanting to record evidence for actions that are not covered by the standard API must use <code>\core_competency\api::add_evidence()</syntaxhighlight>. Note that this method does not perform any capability checks as it is expected to be called as the result of another action which has been authorised. Evidence must not be recorded directly, they always are the result of something else. For that reason there is not any external function to add a piece of evidence.



==Frontend== ==Frontend==



The competency API comes without any frontend, though Moodle core ships with the admin tool <code>tool_lp</code> which is acting as the default frontend for competencies. It includes templates, javascript (AMD modules) and some additional external functions. It was built split from the backend to easily allow the support for other frontends. The competency API comes without any frontend, though Moodle core ships with the admin tool <code>tool_lp</syntaxhighlight> which is acting as the default frontend for competencies. It includes templates, javascript (AMD modules) and some additional external functions. It was built split from the backend to easily allow the support for other frontends.



===URL resolver=== ===URL resolver===
Line 35:
Line 35:
As some of the core APIs require a knowledge of the resource URLs, we introduced the concept of a URL resolver. The URL resolver is used to determine the location of a resource from core, without forcing the default frontend to be used. As some of the core APIs require a knowledge of the resource URLs, we introduced the concept of a URL resolver. The URL resolver is used to determine the location of a resource from core, without forcing the default frontend to be used.



When referring to a resource from ''core'', use the corresponding <code>\core_competency\url::my_ressource_name()</code> method. Note that it is acceptable for a plugin to directly link to resource frontends within itself without using the resolver. When referring to a resource from ''core'', use the corresponding <code>\core_competency\url::my_ressource_name()</syntaxhighlight> method. Note that it is acceptable for a plugin to directly link to resource frontends within itself without using the resolver.



====Defining new URLs==== ====Defining new URLs====
Line 41:
Line 41:
Create a class and implement each routing method defined in [https://git.moodle.org/gw?p=moodle.git;a=blob;f=competency/classes/url.php \core_competency\url], though they should not be static, take [https://git.moodle.org/gw?p=moodle.git;a=blob;f=admin/tool/lp/classes/url_resolver.php \tool_lp\url_resolver] as a base or an example. Create a class and implement each routing method defined in [https://git.moodle.org/gw?p=moodle.git;a=blob;f=competency/classes/url.php \core_competency\url], though they should not be static, take [https://git.moodle.org/gw?p=moodle.git;a=blob;f=admin/tool/lp/classes/url_resolver.php \tool_lp\url_resolver] as a base or an example.



Then indicate to core what class to use by defining the config variable <code>$CFG->core_competency_url_resolver</code>. Then indicate to core what class to use by defining the config variable <code>$CFG->core_competency_url_resolver</syntaxhighlight>.



<code php> <code php>
$CFG->core_competency_url_resolver = '\\your_namespace\\your_class'; $CFG->core_competency_url_resolver = '\\your_namespace\\your_class';
</code> </syntaxhighlight>



==Internal API== ==Internal API==
Line 51:
Line 51:
===Persistents, or Models=== ===Persistents, or Models===



The class <code>\core_competency\persistent</code> represents an object in the database. It is typically what is called a model in general. It contains the list of fields present in the database table, as well as their <code>PARAM_*</code> types. Basic validation of the param types is automatically performed prior to any database write operation. Additional validation can also be added by developers. In essence, the persistent knows everything about its data and when it is valid or not. Persistents are able to CRUD themselves in the database. They are also the right place to perform complex queries which join multiple persistents together. The class <code>\core_competency\persistent</syntaxhighlight> represents an object in the database. It is typically what is called a model in general. It contains the list of fields present in the database table, as well as their <code>PARAM_*</syntaxhighlight> types. Basic validation of the param types is automatically performed prior to any database write operation. Additional validation can also be added by developers. In essence, the persistent knows everything about its data and when it is valid or not. Persistents are able to CRUD themselves in the database. They are also the right place to perform complex queries which join multiple persistents together.



There is never any access control performed within the persistent! However, the competency API is oriented towards model-based Access Control List (ACL), therefore some of the persistents contain helper ACL methods (<code>boolean function can_do_the_thing();</code>). The main benefit of adding ACL methods to the persistent is to avoid repeating the capability names all over the place, and thus reducing code complexity and human errors. There is never any access control performed within the persistent! However, the competency API is oriented towards model-based Access Control List (ACL), therefore some of the persistents contain helper ACL methods (<code>boolean function can_do_the_thing();</syntaxhighlight>). The main benefit of adding ACL methods to the persistent is to avoid repeating the capability names all over the place, and thus reducing code complexity and human errors.



Here is a non-exaustive list of the persistents: Here is a non-exaustive list of the persistents:
Line 126:
Line 126:
Exporters can also define ''related'' objects. When specified those must be set prior to exporting the data, mainly to improve performance. At this stage they may be a bit weak and difficult to work with as adding ''related'' objects to an existing exporter will require all usage of this exporter to be updated. We have raised an issue to try to improve their design: MDL-53052. Exporters can also define ''related'' objects. When specified those must be set prior to exporting the data, mainly to improve performance. At this stage they may be a bit weak and difficult to work with as adding ''related'' objects to an existing exporter will require all usage of this exporter to be updated. We have raised an issue to try to improve their design: MDL-53052.



Exporters have come in very handy when we had to add new properties to persistents, or to export new properties from an existing object. They greatly simplify the maintainability of external functions and <code>templatable::export_for_template()</code>. Exporters have come in very handy when we had to add new properties to persistents, or to export new properties from an existing object. They greatly simplify the maintainability of external functions and <code>templatable::export_for_template()</syntaxhighlight>.



====Formatting, filters, context, etc...==== ====Formatting, filters, context, etc...====



During export, the exporters will take care of formatting the text fields to be ready for output. This means that you do not need to worry about <code>format_string()</code> and <code>format_text()</code>. The filters, sanitization rules, etc... will automatically be applied. The exporter will use the related object <code>context</code> to determine the context of the strings. During export, the exporters will take care of formatting the text fields to be ready for output. This means that you do not need to worry about <code>format_string()</syntaxhighlight> and <code>format_text()</syntaxhighlight>. The filters, sanitization rules, etc... will automatically be applied. The exporter will use the related object <code>context</syntaxhighlight> to determine the context of the strings.



The function <code>format_text()</code> is applied to properties of type <code>PARAM_RAW</code> when another property with the same name ending with ''format'' is also present. For instance, a <code>PARAM_RAW</code> property named ''description'' will be formatted when another property named ''descriptionformat'' is present. The function <code>format_string()</code> is applied to properties of type <code>PARAM_TEXT</code>. The function <code>format_text()</syntaxhighlight> is applied to properties of type <code>PARAM_RAW</syntaxhighlight> when another property with the same name ending with ''format'' is also present. For instance, a <code>PARAM_RAW</syntaxhighlight> property named ''description'' will be formatted when another property named ''descriptionformat'' is present. The function <code>format_string()</syntaxhighlight> is applied to properties of type <code>PARAM_TEXT</syntaxhighlight>.



It is important to note that after formatting the values can contain HTML and will therefore have to be treated as <code>PARAM_RAW</code>. It is important to note that after formatting the values can contain HTML and will therefore have to be treated as <code>PARAM_RAW</syntaxhighlight>.



Damyon at 02:10, 27 May 2016
2016-05-27T02:10:39Z


				
				
				
				
				
				← Older revision
				Revision as of 02:10, 27 May 2016
				
Line 1:
Line 1:
{{Moodle 3.1}} {{Moodle 3.1}}
The competency API lives in the subsystem ''competency'', namespaced <code>\core_competency\</code> and located in the root folder ''competency''. The competency API lives in the subsystem ''competency'', namespaced <code>\core_competency\</code> and located in the root folder ''competency''.

==Mental Models==
These are not diagrams of the database tables exactly - but do show the relation ships between the major components of the competencies API.

[[Image:Competencies and learning plan templates.png|frame|center|Competencies and learning plan templates]]

[[Image:Competencies and courses.png|frame|center|Competencies and courses]]

[[Image:Competencies and unlinked plans.png|frame|center|Competencies and unlinked plans]]



==Public API== ==Public API==



Fmcorz: /* Formatting, filters, context, etc... */
2016-05-13T04:14:28Z
Formatting, filters, context, etc...

				
				
				
				
				
				← Older revision
				Revision as of 04:14, 13 May 2016
				
Line 125:
Line 125:
The function <code>format_text()</code> is applied to properties of type <code>PARAM_RAW</code> when another property with the same name ending with ''format'' is also present. For instance, a <code>PARAM_RAW</code> property named ''description'' will be formatted when another property named ''descriptionformat'' is present. The function <code>format_string()</code> is applied to properties of type <code>PARAM_TEXT</code>. The function <code>format_text()</code> is applied to properties of type <code>PARAM_RAW</code> when another property with the same name ending with ''format'' is also present. For instance, a <code>PARAM_RAW</code> property named ''description'' will be formatted when another property named ''descriptionformat'' is present. The function <code>format_string()</code> is applied to properties of type <code>PARAM_TEXT</code>.



It is important to note that after formatting both content can contain HTML and will therefore have to be treated as <code>PARAM_RAW</code>. It is important to note that after formatting the values can contain HTML and will therefore have to be treated as <code>PARAM_RAW</code>.



Fmcorz: /* Exporters */
2016-05-13T04:12:48Z
Exporters

				
				
				
				
				
				← Older revision
				Revision as of 04:12, 13 May 2016
				
Line 118:
Line 118:



Exporters have come in very handy when we had to add new properties to persistents, or to export new properties from an existing object. They greatly simplify the maintainability of external functions and <code>templatable::export_for_template()</code>. Exporters have come in very handy when we had to add new properties to persistents, or to export new properties from an existing object. They greatly simplify the maintainability of external functions and <code>templatable::export_for_template()</code>.

====Formatting, filters, context, etc...====

During export, the exporters will take care of formatting the text fields to be ready for output. This means that you do not need to worry about <code>format_string()</code> and <code>format_text()</code>. The filters, sanitization rules, etc... will automatically be applied. The exporter will use the related object <code>context</code> to determine the context of the strings.

The function <code>format_text()</code> is applied to properties of type <code>PARAM_RAW</code> when another property with the same name ending with ''format'' is also present. For instance, a <code>PARAM_RAW</code> property named ''description'' will be formatted when another property named ''descriptionformat'' is present. The function <code>format_string()</code> is applied to properties of type <code>PARAM_TEXT</code>.

It is important to note that after formatting both content can contain HTML and will therefore have to be treated as <code>PARAM_RAW</code>.



Fmcorz: /* Custom evidence */
2016-05-02T09:50:38Z
Custom evidence

				
				
				
				
				
				← Older revision
				Revision as of 09:50, 2 May 2016
				
Line 16:
Line 16:
===Custom evidence=== ===Custom evidence===



Developers wanting to record evidence for actions that are not covered by the standard API must use <code>\core_competency\api::add_evidence()</code>. Note that this method does not perform any capability checks as it is expected to be called as the result of another action which has been authorised. Evidence are must not be recorded directly they always are the result of something else. Developers wanting to record evidence for actions that are not covered by the standard API must use <code>\core_competency\api::add_evidence()</code>. Note that this method does not perform any capability checks as it is expected to be called as the result of another action which has been authorised. Evidence must not be recorded directly, they always are the result of something else. For that reason there is not any external function to add a piece of evidence.



==Frontend== ==Frontend==



Fmcorz at 09:48, 2 May 2016
2016-05-02T09:48:18Z


				
				
				
				
				
				← Older revision
				Revision as of 09:48, 2 May 2016
				
Line 9:
Line 9:



[https://git.moodle.org/gw?p=moodle.git;a=blob;f=competency/classes/external.php External functions] are all located in <code>\core_competency\external</code>, mostly as a proxy to the public API. [https://git.moodle.org/gw?p=moodle.git;a=blob;f=competency/classes/external.php External functions] are all located in <code>\core_competency\external</code>, mostly as a proxy to the public API.

==Evidence==

A piece of evidence is used as a record of an action that may affect the competency rating of a student. For instance, when a teacher rates a student in a course, a piece of evidence will be created to record who, what, where, when the rating had been done, in this case it would contain as much as: "The teacher Bob rated the competency 'Demonstrates understanding of French' of the student Ann in the course 'Introduction to French' with the rating 'Met' on the 3rd of January at 1pm".

===Custom evidence===

Developers wanting to record evidence for actions that are not covered by the standard API must use <code>\core_competency\api::add_evidence()</code>. Note that this method does not perform any capability checks as it is expected to be called as the result of another action which has been authorised. Evidence are must not be recorded directly they always are the result of something else.



==Frontend== ==Frontend==



FMCorz: /* Public API */
2016-04-21T03:23:58Z
Public API

				
				
				
				
				
				← Older revision
				Revision as of 03:23, 21 April 2016
				
Line 4:
Line 4:
==Public API== ==Public API==



The public [https://git.moodle.org/gw?p=moodle.git;a=blob;f=competency/classes/api.php API class] contains all the methods which are publicly available to any code taking action on competency related objects and data. No code should ever directly call the database, or persistent (models) methods, unless they are within an API method. All public API methods MUST perform the capability checks relevant to the actions that they are representing. The API methods can be seen as the controllers, they are a mandatory step to accessing the data, even within the competency API itself. The public API is defined by the [https://git.moodle.org/gw?p=moodle.git;a=blob;f=competency/classes/api.php API class] which contains all the methods publicly available to any code taking action on competency related objects and data. No code should ever directly call the database, or persistent (models) methods, unless they are within an API method. All public API methods MUST perform the capability checks relevant to the actions that they are representing. The API methods can be seen as the controllers, they are a mandatory step to accessing the data, even within the competency API itself.



==External API== ==External API==

← Older revision		Revision as of 13:39, 14 July 2021
Line 43:		Line 43:
	Then indicate to core what class to use by defining the config variable <syntaxhighlight lang="php">$CFG->core_competency_url_resolver</syntaxhighlight>.		Then indicate to core what class to use by defining the config variable <syntaxhighlight lang="php">$CFG->core_competency_url_resolver</syntaxhighlight>.

	<~~code~~ php>		<syntaxhighlight lang="php">
	$CFG->core_competency_url_resolver = '\\your_namespace\\your_class';		$CFG->core_competency_url_resolver = '\\your_namespace\\your_class';
	</syntaxhighlight>		</syntaxhighlight>

← Older revision		Revision as of 13:23, 14 July 2021
Line 57:		Line 57:
	Here is a non-exaustive list of the persistents:		Here is a non-exaustive list of the persistents:

	{\| class="~~nicetable~~"		{\| class="wikitable"
	\|-		\|-
	\| competency		\| competency

← Older revision		Revision as of 13:05, 14 July 2021
Line 1:		Line 1:
	{{Moodle 3.1}}		{{Moodle 3.1}}
	The competency API lives in the subsystem ''competency'', namespaced <~~code~~>\core_competency\</syntaxhighlight> and located in the root folder ''competency''.		The competency API lives in the subsystem ''competency'', namespaced <syntaxhighlight lang="php">\core_competency\</syntaxhighlight> and located in the root folder ''competency''.

	==Mental Models==		==Mental Models==
Line 17:		Line 17:
	==External API==		==External API==

	[https://git.moodle.org/gw?p=moodle.git;a=blob;f=competency/classes/external.php External functions] are all located in <~~code~~>\core_competency\external</syntaxhighlight>, mostly as a proxy to the public API.		[https://git.moodle.org/gw?p=moodle.git;a=blob;f=competency/classes/external.php External functions] are all located in <syntaxhighlight lang="php">\core_competency\external</syntaxhighlight>, mostly as a proxy to the public API.

	==Evidence==		==Evidence==
Line 25:		Line 25:
	===Custom evidence===		===Custom evidence===

	Developers wanting to record evidence for actions that are not covered by the standard API must use <~~code~~>\core_competency\api::add_evidence()</syntaxhighlight>. Note that this method does not perform any capability checks as it is expected to be called as the result of another action which has been authorised. Evidence must not be recorded directly, they always are the result of something else. For that reason there is not any external function to add a piece of evidence.		Developers wanting to record evidence for actions that are not covered by the standard API must use <syntaxhighlight lang="php">\core_competency\api::add_evidence()</syntaxhighlight>. Note that this method does not perform any capability checks as it is expected to be called as the result of another action which has been authorised. Evidence must not be recorded directly, they always are the result of something else. For that reason there is not any external function to add a piece of evidence.

	==Frontend==		==Frontend==

	The competency API comes without any frontend, though Moodle core ships with the admin tool <~~code~~>tool_lp</syntaxhighlight> which is acting as the default frontend for competencies. It includes templates, javascript (AMD modules) and some additional external functions. It was built split from the backend to easily allow the support for other frontends.		The competency API comes without any frontend, though Moodle core ships with the admin tool <syntaxhighlight lang="php">tool_lp</syntaxhighlight> which is acting as the default frontend for competencies. It includes templates, javascript (AMD modules) and some additional external functions. It was built split from the backend to easily allow the support for other frontends.

	===URL resolver===		===URL resolver===
Line 35:		Line 35:
	As some of the core APIs require a knowledge of the resource URLs, we introduced the concept of a URL resolver. The URL resolver is used to determine the location of a resource from core, without forcing the default frontend to be used.		As some of the core APIs require a knowledge of the resource URLs, we introduced the concept of a URL resolver. The URL resolver is used to determine the location of a resource from core, without forcing the default frontend to be used.

	When referring to a resource from ''core'', use the corresponding <~~code~~>\core_competency\url::my_ressource_name()</syntaxhighlight> method. Note that it is acceptable for a plugin to directly link to resource frontends within itself without using the resolver.		When referring to a resource from ''core'', use the corresponding <syntaxhighlight lang="php">\core_competency\url::my_ressource_name()</syntaxhighlight> method. Note that it is acceptable for a plugin to directly link to resource frontends within itself without using the resolver.

	====Defining new URLs====		====Defining new URLs====
Line 41:		Line 41:
	Create a class and implement each routing method defined in [https://git.moodle.org/gw?p=moodle.git;a=blob;f=competency/classes/url.php \core_competency\url], though they should not be static, take [https://git.moodle.org/gw?p=moodle.git;a=blob;f=admin/tool/lp/classes/url_resolver.php \tool_lp\url_resolver] as a base or an example.		Create a class and implement each routing method defined in [https://git.moodle.org/gw?p=moodle.git;a=blob;f=competency/classes/url.php \core_competency\url], though they should not be static, take [https://git.moodle.org/gw?p=moodle.git;a=blob;f=admin/tool/lp/classes/url_resolver.php \tool_lp\url_resolver] as a base or an example.

	Then indicate to core what class to use by defining the config variable <~~code~~>$CFG->core_competency_url_resolver</syntaxhighlight>.		Then indicate to core what class to use by defining the config variable <syntaxhighlight lang="php">$CFG->core_competency_url_resolver</syntaxhighlight>.

	<code php>		<code php>
Line 51:		Line 51:
	===Persistents, or Models===		===Persistents, or Models===

	The class <~~code~~>\core_competency\persistent</syntaxhighlight> represents an object in the database. It is typically what is called a model in general. It contains the list of fields present in the database table, as well as their <~~code~~>PARAM_*</syntaxhighlight> types. Basic validation of the param types is automatically performed prior to any database write operation. Additional validation can also be added by developers. In essence, the persistent knows everything about its data and when it is valid or not. Persistents are able to CRUD themselves in the database. They are also the right place to perform complex queries which join multiple persistents together.		The class <syntaxhighlight lang="php">\core_competency\persistent</syntaxhighlight> represents an object in the database. It is typically what is called a model in general. It contains the list of fields present in the database table, as well as their <syntaxhighlight lang="php">PARAM_*</syntaxhighlight> types. Basic validation of the param types is automatically performed prior to any database write operation. Additional validation can also be added by developers. In essence, the persistent knows everything about its data and when it is valid or not. Persistents are able to CRUD themselves in the database. They are also the right place to perform complex queries which join multiple persistents together.

	There is never any access control performed within the persistent! However, the competency API is oriented towards model-based Access Control List (ACL), therefore some of the persistents contain helper ACL methods (<~~code~~>boolean function can_do_the_thing();</syntaxhighlight>). The main benefit of adding ACL methods to the persistent is to avoid repeating the capability names all over the place, and thus reducing code complexity and human errors.		There is never any access control performed within the persistent! However, the competency API is oriented towards model-based Access Control List (ACL), therefore some of the persistents contain helper ACL methods (<syntaxhighlight lang="php">boolean function can_do_the_thing();</syntaxhighlight>). The main benefit of adding ACL methods to the persistent is to avoid repeating the capability names all over the place, and thus reducing code complexity and human errors.

	Here is a non-exaustive list of the persistents:		Here is a non-exaustive list of the persistents:
Line 126:		Line 126:
	Exporters can also define ''related'' objects. When specified those must be set prior to exporting the data, mainly to improve performance. At this stage they may be a bit weak and difficult to work with as adding ''related'' objects to an existing exporter will require all usage of this exporter to be updated. We have raised an issue to try to improve their design: MDL-53052.		Exporters can also define ''related'' objects. When specified those must be set prior to exporting the data, mainly to improve performance. At this stage they may be a bit weak and difficult to work with as adding ''related'' objects to an existing exporter will require all usage of this exporter to be updated. We have raised an issue to try to improve their design: MDL-53052.

	Exporters have come in very handy when we had to add new properties to persistents, or to export new properties from an existing object. They greatly simplify the maintainability of external functions and <~~code~~>templatable::export_for_template()</syntaxhighlight>.		Exporters have come in very handy when we had to add new properties to persistents, or to export new properties from an existing object. They greatly simplify the maintainability of external functions and <syntaxhighlight lang="php">templatable::export_for_template()</syntaxhighlight>.

	====Formatting, filters, context, etc...====		====Formatting, filters, context, etc...====

	During export, the exporters will take care of formatting the text fields to be ready for output. This means that you do not need to worry about <~~code~~>format_string()</syntaxhighlight> and <~~code~~>format_text()</syntaxhighlight>. The filters, sanitization rules, etc... will automatically be applied. The exporter will use the related object <~~code~~>context</syntaxhighlight> to determine the context of the strings.		During export, the exporters will take care of formatting the text fields to be ready for output. This means that you do not need to worry about <syntaxhighlight lang="php">format_string()</syntaxhighlight> and <syntaxhighlight lang="php">format_text()</syntaxhighlight>. The filters, sanitization rules, etc... will automatically be applied. The exporter will use the related object <syntaxhighlight lang="php">context</syntaxhighlight> to determine the context of the strings.

	The function <~~code~~>format_text()</syntaxhighlight> is applied to properties of type <~~code~~>PARAM_RAW</syntaxhighlight> when another property with the same name ending with ''format'' is also present. For instance, a <~~code~~>PARAM_RAW</syntaxhighlight> property named ''description'' will be formatted when another property named ''descriptionformat'' is present. The function <~~code~~>format_string()</syntaxhighlight> is applied to properties of type <~~code~~>PARAM_TEXT</syntaxhighlight>.		The function <syntaxhighlight lang="php">format_text()</syntaxhighlight> is applied to properties of type <syntaxhighlight lang="php">PARAM_RAW</syntaxhighlight> when another property with the same name ending with ''format'' is also present. For instance, a <syntaxhighlight lang="php">PARAM_RAW</syntaxhighlight> property named ''description'' will be formatted when another property named ''descriptionformat'' is present. The function <syntaxhighlight lang="php">format_string()</syntaxhighlight> is applied to properties of type <syntaxhighlight lang="php">PARAM_TEXT</syntaxhighlight>.

	It is important to note that after formatting the values can contain HTML and will therefore have to be treated as <~~code~~>PARAM_RAW</syntaxhighlight>.		It is important to note that after formatting the values can contain HTML and will therefore have to be treated as <syntaxhighlight lang="php">PARAM_RAW</syntaxhighlight>.

← Older revision		Revision as of 13:03, 14 July 2021
Line 1:		Line 1:
	{{Moodle 3.1}}		{{Moodle 3.1}}
	The competency API lives in the subsystem ''competency'', namespaced <code>\core_competency\</~~code~~> and located in the root folder ''competency''.		The competency API lives in the subsystem ''competency'', namespaced <code>\core_competency\</syntaxhighlight> and located in the root folder ''competency''.

	==Mental Models==		==Mental Models==
Line 17:		Line 17:
	==External API==		==External API==

	[https://git.moodle.org/gw?p=moodle.git;a=blob;f=competency/classes/external.php External functions] are all located in <code>\core_competency\external</~~code~~>, mostly as a proxy to the public API.		[https://git.moodle.org/gw?p=moodle.git;a=blob;f=competency/classes/external.php External functions] are all located in <code>\core_competency\external</syntaxhighlight>, mostly as a proxy to the public API.

	==Evidence==		==Evidence==
Line 25:		Line 25:
	===Custom evidence===		===Custom evidence===

	Developers wanting to record evidence for actions that are not covered by the standard API must use <code>\core_competency\api::add_evidence()</~~code~~>. Note that this method does not perform any capability checks as it is expected to be called as the result of another action which has been authorised. Evidence must not be recorded directly, they always are the result of something else. For that reason there is not any external function to add a piece of evidence.		Developers wanting to record evidence for actions that are not covered by the standard API must use <code>\core_competency\api::add_evidence()</syntaxhighlight>. Note that this method does not perform any capability checks as it is expected to be called as the result of another action which has been authorised. Evidence must not be recorded directly, they always are the result of something else. For that reason there is not any external function to add a piece of evidence.

	==Frontend==		==Frontend==

	The competency API comes without any frontend, though Moodle core ships with the admin tool <code>tool_lp</~~code~~> which is acting as the default frontend for competencies. It includes templates, javascript (AMD modules) and some additional external functions. It was built split from the backend to easily allow the support for other frontends.		The competency API comes without any frontend, though Moodle core ships with the admin tool <code>tool_lp</syntaxhighlight> which is acting as the default frontend for competencies. It includes templates, javascript (AMD modules) and some additional external functions. It was built split from the backend to easily allow the support for other frontends.

	===URL resolver===		===URL resolver===
Line 35:		Line 35:
	As some of the core APIs require a knowledge of the resource URLs, we introduced the concept of a URL resolver. The URL resolver is used to determine the location of a resource from core, without forcing the default frontend to be used.		As some of the core APIs require a knowledge of the resource URLs, we introduced the concept of a URL resolver. The URL resolver is used to determine the location of a resource from core, without forcing the default frontend to be used.

	When referring to a resource from ''core'', use the corresponding <code>\core_competency\url::my_ressource_name()</~~code~~> method. Note that it is acceptable for a plugin to directly link to resource frontends within itself without using the resolver.		When referring to a resource from ''core'', use the corresponding <code>\core_competency\url::my_ressource_name()</syntaxhighlight> method. Note that it is acceptable for a plugin to directly link to resource frontends within itself without using the resolver.

	====Defining new URLs====		====Defining new URLs====
Line 41:		Line 41:
	Create a class and implement each routing method defined in [https://git.moodle.org/gw?p=moodle.git;a=blob;f=competency/classes/url.php \core_competency\url], though they should not be static, take [https://git.moodle.org/gw?p=moodle.git;a=blob;f=admin/tool/lp/classes/url_resolver.php \tool_lp\url_resolver] as a base or an example.		Create a class and implement each routing method defined in [https://git.moodle.org/gw?p=moodle.git;a=blob;f=competency/classes/url.php \core_competency\url], though they should not be static, take [https://git.moodle.org/gw?p=moodle.git;a=blob;f=admin/tool/lp/classes/url_resolver.php \tool_lp\url_resolver] as a base or an example.

	Then indicate to core what class to use by defining the config variable <code>$CFG->core_competency_url_resolver</~~code~~>.		Then indicate to core what class to use by defining the config variable <code>$CFG->core_competency_url_resolver</syntaxhighlight>.

	<code php>		<code php>
	$CFG->core_competency_url_resolver = '\\your_namespace\\your_class';		$CFG->core_competency_url_resolver = '\\your_namespace\\your_class';
	</~~code~~>		</syntaxhighlight>

	==Internal API==		==Internal API==
Line 51:		Line 51:
	===Persistents, or Models===		===Persistents, or Models===

	The class <code>\core_competency\persistent</~~code~~> represents an object in the database. It is typically what is called a model in general. It contains the list of fields present in the database table, as well as their <code>PARAM_*</~~code~~> types. Basic validation of the param types is automatically performed prior to any database write operation. Additional validation can also be added by developers. In essence, the persistent knows everything about its data and when it is valid or not. Persistents are able to CRUD themselves in the database. They are also the right place to perform complex queries which join multiple persistents together.		The class <code>\core_competency\persistent</syntaxhighlight> represents an object in the database. It is typically what is called a model in general. It contains the list of fields present in the database table, as well as their <code>PARAM_*</syntaxhighlight> types. Basic validation of the param types is automatically performed prior to any database write operation. Additional validation can also be added by developers. In essence, the persistent knows everything about its data and when it is valid or not. Persistents are able to CRUD themselves in the database. They are also the right place to perform complex queries which join multiple persistents together.

	There is never any access control performed within the persistent! However, the competency API is oriented towards model-based Access Control List (ACL), therefore some of the persistents contain helper ACL methods (<code>boolean function can_do_the_thing();</~~code~~>). The main benefit of adding ACL methods to the persistent is to avoid repeating the capability names all over the place, and thus reducing code complexity and human errors.		There is never any access control performed within the persistent! However, the competency API is oriented towards model-based Access Control List (ACL), therefore some of the persistents contain helper ACL methods (<code>boolean function can_do_the_thing();</syntaxhighlight>). The main benefit of adding ACL methods to the persistent is to avoid repeating the capability names all over the place, and thus reducing code complexity and human errors.

	Here is a non-exaustive list of the persistents:		Here is a non-exaustive list of the persistents:
Line 126:		Line 126:
	Exporters can also define ''related'' objects. When specified those must be set prior to exporting the data, mainly to improve performance. At this stage they may be a bit weak and difficult to work with as adding ''related'' objects to an existing exporter will require all usage of this exporter to be updated. We have raised an issue to try to improve their design: MDL-53052.		Exporters can also define ''related'' objects. When specified those must be set prior to exporting the data, mainly to improve performance. At this stage they may be a bit weak and difficult to work with as adding ''related'' objects to an existing exporter will require all usage of this exporter to be updated. We have raised an issue to try to improve their design: MDL-53052.

	Exporters have come in very handy when we had to add new properties to persistents, or to export new properties from an existing object. They greatly simplify the maintainability of external functions and <code>templatable::export_for_template()</~~code~~>.		Exporters have come in very handy when we had to add new properties to persistents, or to export new properties from an existing object. They greatly simplify the maintainability of external functions and <code>templatable::export_for_template()</syntaxhighlight>.

	====Formatting, filters, context, etc...====		====Formatting, filters, context, etc...====

	During export, the exporters will take care of formatting the text fields to be ready for output. This means that you do not need to worry about <code>format_string()</~~code~~> and <code>format_text()</~~code~~>. The filters, sanitization rules, etc... will automatically be applied. The exporter will use the related object <code>context</~~code~~> to determine the context of the strings.		During export, the exporters will take care of formatting the text fields to be ready for output. This means that you do not need to worry about <code>format_string()</syntaxhighlight> and <code>format_text()</syntaxhighlight>. The filters, sanitization rules, etc... will automatically be applied. The exporter will use the related object <code>context</syntaxhighlight> to determine the context of the strings.

	The function <code>format_text()</~~code~~> is applied to properties of type <code>PARAM_RAW</~~code~~> when another property with the same name ending with ''format'' is also present. For instance, a <code>PARAM_RAW</~~code~~> property named ''description'' will be formatted when another property named ''descriptionformat'' is present. The function <code>format_string()</~~code~~> is applied to properties of type <code>PARAM_TEXT</~~code~~>.		The function <code>format_text()</syntaxhighlight> is applied to properties of type <code>PARAM_RAW</syntaxhighlight> when another property with the same name ending with ''format'' is also present. For instance, a <code>PARAM_RAW</syntaxhighlight> property named ''description'' will be formatted when another property named ''descriptionformat'' is present. The function <code>format_string()</syntaxhighlight> is applied to properties of type <code>PARAM_TEXT</syntaxhighlight>.

	It is important to note that after formatting the values can contain HTML and will therefore have to be treated as <code>PARAM_RAW</~~code~~>.		It is important to note that after formatting the values can contain HTML and will therefore have to be treated as <code>PARAM_RAW</syntaxhighlight>.

← Older revision		Revision as of 02:10, 27 May 2016
Line 1:		Line 1:
	{{Moodle 3.1}}		{{Moodle 3.1}}
	The competency API lives in the subsystem ''competency'', namespaced <code>\core_competency\</code> and located in the root folder ''competency''.		The competency API lives in the subsystem ''competency'', namespaced <code>\core_competency\</code> and located in the root folder ''competency''.

			==Mental Models==
			These are not diagrams of the database tables exactly - but do show the relation ships between the major components of the competencies API.

			[[Image:Competencies and learning plan templates.png\|frame\|center\|Competencies and learning plan templates]]

			[[Image:Competencies and courses.png\|frame\|center\|Competencies and courses]]

			[[Image:Competencies and unlinked plans.png\|frame\|center\|Competencies and unlinked plans]]

	==Public API==		==Public API==

← Older revision		Revision as of 04:14, 13 May 2016
Line 125:		Line 125:
	The function <code>format_text()</code> is applied to properties of type <code>PARAM_RAW</code> when another property with the same name ending with ''format'' is also present. For instance, a <code>PARAM_RAW</code> property named ''description'' will be formatted when another property named ''descriptionformat'' is present. The function <code>format_string()</code> is applied to properties of type <code>PARAM_TEXT</code>.		The function <code>format_text()</code> is applied to properties of type <code>PARAM_RAW</code> when another property with the same name ending with ''format'' is also present. For instance, a <code>PARAM_RAW</code> property named ''description'' will be formatted when another property named ''descriptionformat'' is present. The function <code>format_string()</code> is applied to properties of type <code>PARAM_TEXT</code>.

	It is important to note that after formatting ~~both content~~ can contain HTML and will therefore have to be treated as <code>PARAM_RAW</code>.		It is important to note that after formatting the values can contain HTML and will therefore have to be treated as <code>PARAM_RAW</code>.

← Older revision		Revision as of 04:12, 13 May 2016
Line 118:		Line 118:

	Exporters have come in very handy when we had to add new properties to persistents, or to export new properties from an existing object. They greatly simplify the maintainability of external functions and <code>templatable::export_for_template()</code>.		Exporters have come in very handy when we had to add new properties to persistents, or to export new properties from an existing object. They greatly simplify the maintainability of external functions and <code>templatable::export_for_template()</code>.

			====Formatting, filters, context, etc...====

			During export, the exporters will take care of formatting the text fields to be ready for output. This means that you do not need to worry about <code>format_string()</code> and <code>format_text()</code>. The filters, sanitization rules, etc... will automatically be applied. The exporter will use the related object <code>context</code> to determine the context of the strings.

			The function <code>format_text()</code> is applied to properties of type <code>PARAM_RAW</code> when another property with the same name ending with ''format'' is also present. For instance, a <code>PARAM_RAW</code> property named ''description'' will be formatted when another property named ''descriptionformat'' is present. The function <code>format_string()</code> is applied to properties of type <code>PARAM_TEXT</code>.

			It is important to note that after formatting both content can contain HTML and will therefore have to be treated as <code>PARAM_RAW</code>.

← Older revision		Revision as of 09:50, 2 May 2016
Line 16:		Line 16:
	===Custom evidence===		===Custom evidence===

	Developers wanting to record evidence for actions that are not covered by the standard API must use <code>\core_competency\api::add_evidence()</code>. Note that this method does not perform any capability checks as it is expected to be called as the result of another action which has been authorised. Evidence ~~are~~ must not be recorded directly they always are the result of something else.		Developers wanting to record evidence for actions that are not covered by the standard API must use <code>\core_competency\api::add_evidence()</code>. Note that this method does not perform any capability checks as it is expected to be called as the result of another action which has been authorised. Evidence must not be recorded directly, they always are the result of something else. For that reason there is not any external function to add a piece of evidence.

	==Frontend==		==Frontend==

← Older revision		Revision as of 09:48, 2 May 2016
Line 9:		Line 9:

	[https://git.moodle.org/gw?p=moodle.git;a=blob;f=competency/classes/external.php External functions] are all located in <code>\core_competency\external</code>, mostly as a proxy to the public API.		[https://git.moodle.org/gw?p=moodle.git;a=blob;f=competency/classes/external.php External functions] are all located in <code>\core_competency\external</code>, mostly as a proxy to the public API.

			==Evidence==

			A piece of evidence is used as a record of an action that may affect the competency rating of a student. For instance, when a teacher rates a student in a course, a piece of evidence will be created to record who, what, where, when the rating had been done, in this case it would contain as much as: "The teacher Bob rated the competency 'Demonstrates understanding of French' of the student Ann in the course 'Introduction to French' with the rating 'Met' on the 3rd of January at 1pm".

			===Custom evidence===

			Developers wanting to record evidence for actions that are not covered by the standard API must use <code>\core_competency\api::add_evidence()</code>. Note that this method does not perform any capability checks as it is expected to be called as the result of another action which has been authorised. Evidence are must not be recorded directly they always are the result of something else.

	==Frontend==		==Frontend==

← Older revision		Revision as of 03:23, 21 April 2016
Line 4:		Line 4:
	==Public API==		==Public API==

	The public [https://git.moodle.org/gw?p=moodle.git;a=blob;f=competency/classes/api.php API class] contains all the methods ~~which are~~ publicly available to any code taking action on competency related objects and data. No code should ever directly call the database, or persistent (models) methods, unless they are within an API method. All public API methods MUST perform the capability checks relevant to the actions that they are representing. The API methods can be seen as the controllers, they are a mandatory step to accessing the data, even within the competency API itself.		The public API is defined by the [https://git.moodle.org/gw?p=moodle.git;a=blob;f=competency/classes/api.php API class] which contains all the methods publicly available to any code taking action on competency related objects and data. No code should ever directly call the database, or persistent (models) methods, unless they are within an API method. All public API methods MUST perform the capability checks relevant to the actions that they are representing. The API methods can be seen as the controllers, they are a mandatory step to accessing the data, even within the competency API itself.

	==External API==		==External API==