Student projects/Admin page cleanup/XML file format: Difference between revisions
mNo edit summary |
mNo edit summary |
||
Line 52: | Line 52: | ||
Next, the attributes. If an attribute has the same name in two different tags (e.g. auth in settingpage and settinggroup), it's because it serves the same purpose in both tags. To that end, I'll only describe what happens to each attribute, not each tag/attribute combination: | Next, the attributes. If an attribute has the same name in two different tags (e.g. auth in settingpage and settinggroup), it's because it serves the same purpose in both tags. To that end, I'll only describe what happens to each attribute, not each tag/attribute combination: | ||
* name should contain the actual text to be displayed to the user (e.g. as the name of the folder, of a settingpage, of an actual setting, etc.) It is parsed through PHP and must contain code that returns a string, for example | * name should contain the actual text to be displayed to the user (e.g. as the name of the folder, of a settingpage, of an actual setting, etc.) It is parsed through PHP and must contain code that returns a string, for example | ||
"User Settings" | "User Settings" | ||
get_string('Administration') | get_string('Administration') | ||
* auth should contain PHP code that evaluates to either true or false to determine whether or not the current user should be given access to the settinggroup, settingpage or category. For example | |||
isadmin() | |||
iscreator() | |||
(in progress...) | |||
[[Category:Developer]] | [[Category:Developer]] | ||
[[Category:Project]] | [[Category:Project]] |
Revision as of 04:09, 23 June 2006
Part of the Student projects/Admin page cleanup project involves coming up with a format for storing the hierarchy of admin settings and general information about the settings. To that end, I've put together the following XML DTD
(N.B. this format is for storing how the settings are organized, not the setting themselves -- those are still stored in the database for reasons of efficiency.)
<!DOCTYPE moodleadmin [ <!ELEMENT moodleadmin (category|settinggroup|settingpage)*> <!ELEMENT category (category|settinggroup|settingpage)*> <!ATTLIST category name CDATA #REQUIRED auth CDATA #REQUIRED> <!ELEMENT settinggroup (setting*)> <!ATTLIST settinggroup name CDATA #REQUIRED auth CDATA #REQUIRED> <!ELEMENT setting EMPTY> <!ATTLIST setting name CDATA #REQUIRED type (text|select|htmledit|checkbox) #REQUIRED selectoptions CDATA #IMPLIED description CDATA #REQUIRED setoninstall (true|false) "false" writeproc CDATA #REQUIRED readproc CDATA #REQUIRED> <!ELEMENT settingpage EMPTY> <!ATTLIST settingpage name CDATA #REQUIRED auth CDATA #REQUIRED hardcoded CDATA #REQUIRED> ]>
Here's a short sample XML file
<moodleadmin> <category name="php_code_must_return_string" auth="php_code_must_return_boolean"> <settinggroup name="php_code_must_return_string" auth="php_code_that_must_return_boolean"> <setting name="php_code_must_return_string" type="(text|select|htmledit|checkbox)" selectoptions="option1,option2,option3" description="php_code_must_return_string" setoninstall="(true|false)" writeproc="php_code_must_return_boolean" readproc="php_code_must_return_string" /> </settinggroup> <settingpage name="php_code_must_return_string" hardcoded="filename.php" auth="php_code_must_return_boolean" /> </category> </moodleadmin>
And now the explanations.
Categories appear in the hierarchical menu as folders, while settinggroups and settingpages appear as actual clickable items. Thus, categories can be nested, while settinggroups and settingpages must appear either within a category or at the moodleadmin root level. Settings must appear in a settinggroup.
Next, the attributes. If an attribute has the same name in two different tags (e.g. auth in settingpage and settinggroup), it's because it serves the same purpose in both tags. To that end, I'll only describe what happens to each attribute, not each tag/attribute combination:
- name should contain the actual text to be displayed to the user (e.g. as the name of the folder, of a settingpage, of an actual setting, etc.) It is parsed through PHP and must contain code that returns a string, for example
"User Settings" get_string('Administration')
- auth should contain PHP code that evaluates to either true or false to determine whether or not the current user should be given access to the settinggroup, settingpage or category. For example
isadmin() iscreator()
(in progress...)