General developer forum

Not that Moodle does not just use QuickForms. We already have our own form API class moodleform. Internally uses HTMLQuickForm for some stuff, but for other Moodle code, the QuickForms API is only partially exposed.

We should definitely get rid of QuickForms internally.

We should not change the API that existing Moodle code uses to create forms if at all possible. That would create huge amounts of work for many people.

(Has anyone tried to count how many forms are defined in Moodle core, and in all the plugins in the plugins DB? That would be useful data that might inform this the design decisions we need to make. Might also be interesting to count how often each element type is used in Moodle code. Also, how often features like repeat_elements, groups of fields, defintion_after_data, hard_freeze, etc. are used. Can anyone conjure up the necessary regular-expression magic to do this?)

So, what should we do. When this has been discussed at hack-fests in the past (which has happened several times over many years) the discussion has normally suggested a plan something like this:

1. Change the moodleform internals, so that when a form is displayed, that is done entirely with Moodle rendering code (that is, templates) not QuickForms.
   
2. Change the moodleform internals, so that when the form is submitted, and we need to validate then get the values out, that is done without any remaining QuickForms stuff. (I think quite a lot of this skips QuickForms already.)
   
3. Change how the moodleform class represents the structure of the form internally, so that the objects for each element are no longer based on the QuickForms classes.
4. At this point, QuickForms is gone.
5. Work out a JSON format for the form data, so that the structure of a form can be sent to JavaScript, and make code to export a form in that structure.
6. Write the JS code that takes that JSON and displays the form.

(2. & 3. might need to be combined. It could well be possible to work on 5. & 6. in parallel to 1. to 3.)

This approach is incremental, and is the best chance of preserving most backwards-compatibility. We will probably be forced to break a few complex and rare things, e.g. people who have defined their own element types.

I also recommend that you look at some of the more complex forms in Moodle. Places I know complexity lies:

• The edit question forms
• The course settings form
• Activity settings forms for the more complex activities (forum, assignment, workshop, quiz, ...)
  

Thanks everyone for joining in on this conversation. Your input has been most valuable. We have created an epic for this issue (MDL-52143). Feel free to continue to make comments there. 

We will now start writing up the specification. Once a specification has been complete, I will create another post in the new features forum.