At the moment, every bit of Moodle makes its own forms for editing by outputting HTML, so there is loads of very similar code all over the place. So if, for example, you wanted to improve the accessibility of all Moodle forms, you would have to go and hack HTML all over the place.
Obviously the accessibility people don't want to do that. Also, perhaps, as developers we would like to stop copying and pasting so many similar bits of HTML, and be able to make our forms much more easily.
So the suggestion is to have a simplified format for describing the form you want at a high level, and then have a library to generate all the repetative HTML.
One approach that is being talked about is XForms, which managers like becuase it is a 'standard'. However, in my opinion, it is an unnecessarily complicated standard that looks like it was designed by a committee (becuase it was).
The other approach, and we (mainly sam) have started doing this at the OU, would be to make up our own Moodle-specific form syntax. Here is a simple example:
<editform langfile='resourcepage'> <item type='text' name='name'/> <item type='html' name='description'/> <visible/> </editform>And to display the form you would do something like:
$xf = xml_form::load_file('editresourcepage.xml'); // This gets the form def from a file. You can also get it from a string. $xf->set_init_html_editor(true); $xf->set_hidden('moduleid',0); // adds a hidden field $form = new stdClass; // To hold the initial value for each form field. $form->name = 'A name'; // ... initialise the other $form fields too ... $xf->show(basename(__FILE__), $form);That would generate a typical create/edit module form. The item type says what sort of control to print (text box, dropdown, html editor*, etc.). The text to use as a label is looked up in the lang file resourcepage.php as field_name, and the help ? icon links to resourcepage/name.html. You can override both these using extra attributes, such as help='' to omit help icon altogether.
<visible/> generates a standard visible to student option by calling print_visible_setting.
Basically, the whole point is to minimise the amount you have to type to get your form. This is just about generating the HTML. You still have to do the required_param, optional_param stuff to process the results, like now.
Here is a more complex example:
<item type='text' name='location'/>
<item type='text' name='name'/>
<item type='text' name='pres'/>
<item type='html' name='summary'/>
<item type='dropdown' name='type'>
<group requiredname="type" requiredvalue="external">
<item type='text' name='url'/>
<group requiredname="type" requiredvalue="internal">
<item type='date' name='startdate'/>
<item type='dropdown' name='public'>
<item type='text' name='defaultauthid'/>
<item type='multitext' name='optionalauthids'/>
<item type='users' name='posters'/>
<item type='users' name='approvers'/>
<a href="editincludes.php?newsfeedid=<?php print $form->newsfeedid ?>">Includes</a>
Things to note are:
- An example of how you do a dropdown. Again, option names like type_internal are looked up in the lang file automatically.
- The <group> stuff shows or hides different bits at the end for the form depending on the dropdown setting.
- More interesting types. For example type="users". This now has some AJAX stuff to check the username in the database as you type.
- You can include arbitrary HTML (and PHP) using the <xhtml> tag. So if the library cannot generate the HTML you want, you can just add it.
This library is still evolving as we find new things we need it to do and implement them. The question is, is this a sensible approach, and should we be thinking about tidying it up and contributing it back to the community? Or is the community going to adopt an alternative approach, as we should stop developing this.
As I say, my colleague sam did most of the work, and I have just used this, and found it really made my life easier.
P.S. sorry this is such a long post.