Hi from QuickForm developers

Hi from QuickForm developers

by Alexey Borzov -
Number of replies: 14

We are finally preparing a stable release of HTML_QuickForm2, a new major version of HTML_QuickForm package used by Moodle to build forms.

While cleaning up our tracker from "exotic" feature requests we found one originating from Moodle: #12065

The request basically left us scratching our heads, as it showed using the package's features in a way that was never really intended. Specifically, the "frozen" display is not just for disabling elements (which can be easily achieved by just setting the "disabled" attribute), but mostly for an additional confirmation step after form submit, sending a filled form via email and similar applications.

I've had a brief look at Moodle form-related code and was even more puzzled.

  • The version of HTML_QuickForm in there is most probably 3.2.6 (maybe 3.2.7) released back in 2006. While we were not adding features to the package, we regularly did bug-fixing releases and the latest one is 3.2.13 released in 2011.
  • Looks like Moodle isn't using stock QuickForm elements, but "customized" ones. I suspect that most of these "customizations" could be implemented in a different way that would also not interfere with an ability to upgrade base package.
  • I don't think I remember bug reports / feature requests / mailing list questions from Moodle developers other than the only one mentioned above. If there were any attempts to contact us, your form library would not end up with such a number of hacks.

So I'd like to clarify a few points

  • Concerning the above feature request, why is Moodle depending so much on "form freezing" feature? What was the idea behind this?
  • Are there plans to upgrade Moodle form library to HTML_QuickForm2?
  • Are there any sacred taboos on communication with upstream package providers among Moodle developers?

If you are indeed interested in upgrading then we have a migration guide available and will gladly answer questions.

Average of ratings: Useful (2)
In reply to Alexey Borzov

Re: Hi from QuickForm developers

by Dan Poltawski -
Hi Alexey,

Thanks for reaching out to us.

I'm afraid i'm not too familiar with our quickforms integration so I can't actually answer your questions.

However, no there are not sacred any sacred taboos on communication with upstream package providers. Clearly we see the benefits of not modifying the core of our upstream being an upstream ourselves!

So - thank you for the code and open source license which allows us to do crazy things with it..

cheers,
dan
Average of ratings: -
In reply to Dan Poltawski

Re: Hi from QuickForm developers

by Alexey Borzov -

Hi Dan,

Thanks for answering: I was not sure whether I chose the right forum for my question. smile

I'd like to expand on my previous message in hope someone close to Moodle forms module notices that thread.

Of course, we took our sweet time in rewriting QuickForm, even the above request is 4+ years old. However, the new version is in beta for almost a year, is pretty stable (and covered by unit tests, unlike the previous one) and e.g. Piwik already migrated from QuickForm to QuickForm2.

We also paid a lot of attention to making it easier to extend the new version with custom elements / validation rules / renderers / javascript / you name it. That is what Moodle did with a previous version, probably having a lot of trouble along the way. The new version should cause far less trouble.

So if there is interest in migration, we'd gladly help with it (and there's of course a clearer migration path from QF to QF2 than from QF to anything else). If there's no interest --- also fine with us, we'll definitely learn something from the library Moodle chooses. Do not try to write one from scratch yourselves, though: it is a monumental task, as we already learned the hard way. smile

Average of ratings: -
In reply to Alexey Borzov

Re: Hi from QuickForm developers

by Dan Marsden -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers Picture of Plugins guardians Picture of Testers Picture of Translators

Hi Alexey - thanks for engaging here in the forums! - I think there's been general consensus that we'd like to migrate from QF to something better but it's a big job and would likely need to be done by Moodle HQ - your offer of help to do this is awesome!

Obviously moving from QF to QF2 would potentially be easier than moving to something like Zend forms - are you aware of any good comparisons between QF2 and other forms libraries that will help us decide to stay with QF2 ?

Average of ratings: -
In reply to Dan Marsden

Re: Hi from QuickForm developers

by Alexey Borzov -

Hi Dan,

I am unfortunately not familiar with Moodle project structure, who are Moodle HQ?

As for comparisons, let me put it that way: even if I knew such a comparison, I am hardly a neutral party. smile

The Piwik guys I mentioned above tried migrating QF -> ZF first, though, before settling on QF -> QF2. Also I am not sure about current ZF, but last time I checked they did not offer client-side validation out of the box. Judging by the presence of HTML_QuickForm_DHTMLRulesTableless add-on in Moodle code and presence of generated client-side validation rules in the source of the page where I'm writing this comment, client-side validation is widely used here.

Average of ratings: -
In reply to Alexey Borzov

Re: Hi from QuickForm developers

by Marcus Green -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers

Moodle HQ are the people who run this site and Moodle.com, which means you are posting in exactly the right place. The do loads of the development and co-ordinate the official release versions.

Average of ratings: -
In reply to Dan Marsden

Re: Hi from QuickForm developers

by Alexey Borzov -

A couple more words about comparisons: there is A PHP and jQuery form creation and validation library available? question at StackOverflow. QF2 managed to come up third on the list even while it does not use jQuery at all and the author couldn't run its client side validation for some reason. big grin

I've looked at the libraries occupying the first two places and wasn't really impressed: they have obvious design problems like hardcoded markup in element classes and hardcoded English messages.

Basically you'll need a list of requirements first before turning to comparisons.

Average of ratings: -
In reply to Alexey Borzov

Re: Hi from QuickForm developers

by Tomasz Muras -
Picture of Core developers Picture of Plugin developers Picture of Plugins guardians Picture of Translators

I know it's a hell lot of work but I would *love* to see Moodle moving to HTML_QuickForm2 and merging with upstream. I imagine that this would require a push from Moodle HQ.

Tomek

Average of ratings: -
In reply to Tomasz Muras

Re: Hi from QuickForm developers

by Matt Gibson -

+1. I've had to do several awkward hacks with mforms which I think would be unnecessary with the extra flexibility if we upgraded.

Average of ratings: -
In reply to Matt Gibson

Re: Hi from QuickForm developers

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

Well, how much time would it take someone to do a quick-and-dirty upgrade of the code. Not anything suitable for acutally being integrated into Moodle core, but just something that mostly works so that we can then see:

  1. That Quickforms2 does basically work in place of Quickforms;
  2. what are all the places where more work is needed, in other words a detailed todo list for a proper upgrade to QF2 in Moodle 2.4 of whenever.
  3. What were all the moodle-specific hacks in the QF integration, that we will need to redo (hopefully in a better way) for QF2.

Any volunteers to start exploring?

Average of ratings: -
In reply to Tim Hunt

Re: Hi from QuickForm developers

by Alexey Borzov -

I've had a brief look at base formslib.php and will try to help a bit with 3.

The moodleform class itself looks like a reinvented wheel HTML_QuickForm_Page from HTML_QuickForm_Controller. Of course, there was a stupid decision in old QF for Page to extend base HTML_QuickForm rather than contain an instance of it, but that is now fixed in QF2 (also Controller infrastructure is now a part of the base package). A large part of moodleform class is about running different actions for different submit buttons, that's what Controller is designed for.

moodleform also contains handlers for repeating elements, we now have a generic repeat element in SVN, will be in the next beta release.

Looks like there is a wrapper for files validation in there, file elements in QF2 are able to validate themselves by checking 'error' field in $_FILES

MoodleQuickForm: working with "advanced" elements can also be done using Controller.

Help buttons can be rendered as additional labels, this was supported in QF as well.

disabledIf() can probably be achieved by writing a custom "Rule" for marking the element disbled and using rule chaining.

As for freeze()-related stuff, I'm still puzzled on its usage in Moodle, so will wait for someone to enlighten me.

Average of ratings: -
In reply to Tim Hunt

Re: Hi from QuickForm developers

by Benjamin Ellis -
Picture of Particularly helpful Moodlers

Would love to if I had the time, sounds like an interesting project - oh well, maybe when my contract ends in Feb and no-one else has decided to carry the torch....

Average of ratings: -
In reply to Alexey Borzov

Re: Hi from QuickForm developers

by Martin Dougiamas -
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers

Alexey,

Thanks very much for getting in touch.  The short answer is that we have a large codebase and have been working on other things and just "getting by" on HTML_Quickform_1+hacks in the meantime. To be honest it looked (at a casual glance) like your project had pretty much stopped.  smile

If you are planning a stable release of  v2 very soon though then I'll make sure we look at upgrading our libraries in our next Moodle release (2.4).  And if we use it, I'll encourage our developers to communicate more with you.  Thanks very much!

Average of ratings: -
In reply to Martin Dougiamas

Re: Hi from QuickForm developers

by Alexey Borzov -

Hi Martin,

Thanks for answering!

Our project had not stopped, it was only paused for a couple of years... I do understand that this fact didn't quite help its image as a viable upgrade path. mixed

But right now we are indeed quite close to declaring QF2 stable, main obstacle is finishing end-user documentation, the code itself is mostly ready. And as you definitely understand, feature additions are easier now than after that magic 2.0.0 version, so we are looking forward to communication.

Average of ratings: -
In reply to Alexey Borzov

Re: Hi from QuickForm developers

by Federico Ghigini -

Hi, are there any news on this front?

Are there any related issue or task?

I have found out that QF2 has been turned stable in 2012-06-26.

Thanks!

Average of ratings: -