David Scotson

I gave it a whirl on a CVS head copy of Moodle. Installation and basic operation seem great. Some comments:

• does Moodle's plain text format disable all filters? I'd never noticed before but thought that the plain text format would be a good fit for this module since code could have all sorts of wierdness in it that you don't want interfered with. On the other hand, it makes sense to have filters disabled for the plain text format because, in a sense, you're saying "don't mess with this text" when you choose it. Maybe this filter could also form the basis of a resource type ('highlighted source code') where the the various options (line numbers etc.) could be exposed in the setup screen?
• leaving off the closing square bracket of the opening tag seems to confuse it. I get a warning (possibly only visible in debug mode) and the text up to the closing tag gets eaten.
• it might be very slightly better HTML to have both pre and code tags wrapping the content though generally this won't have an actual visible impact. It matches better with the choice of [code] as your syntax too.
• is there an inline mode where you could insert variable names or short snippets of code into running text? Probably just code without the pre would be better here (see above point).
• the line number start option and highlight capability interact weirdly i.e. I ask for line number 4 and 5 to be highlighted, and ask it to start at line 4 then it highlights line 8 and 9.
• the div immediately inside the li is probably unnecessary as the li acts as a block element anyway.
• It adds a blank, but numbered line at the end if you don't close the tag on the same line as the last bit of code.
• the padding around the code seems tailored to fit the linenumbered version and seems a bit lopsided when they aren't present.
• I got a weird style duplication, possibly another interaction of highlight, it was only noticeable by viewing the source.

Notice the strange ',' in the middle of the style tag:

div style="font-size:110%;font-family:monospace;font-weight:normal;','font-size:110%;font-family:monospace;"

I can see this being really useful, hopefully Moodle.org can be upgraded to this new version too.

In Kubrick I do nothing, since I hadn't noticed this particular problem. However looking at it now I can see that although the problem is there, it is pretty much disguised because of the particular size and color of Kubrick theme.

Interestingly, Kubrick doesn't have headers in pop-ups, possibly because of code in header.html that looks like this:

<?php if ($home || $heading) {   ?>
    <div id="header">
     etc.

If that php does actually mean "everywhere but pop-ups" (which I seem to recall being the point, since the big Kubrick header looked a bit ridiculous in small pop-up windows) then you could use it to add a pop-up class to the body tag.

Other options include code fiddling e.g. finding the code that sets the width of these pop-ups ( e.g. mod/resource/type/file/file.html) and setting it to the same width as your theme or adding a javascript to your header that detects that width and changes it.

Without getting into the deeper issues, the CSS you posted is incorrect, I think:

body#course-scales,
#course-scales#page {
    width:auto !important;
    background:#fff !important;
}

The second line (#course-scales#page) is missing a space before the second #. That might solve your problem. You might want to try validating your CSS to try and catch any other typos that might be affecting things.

There's certainly no reason why you shouldn't be able to specify different widths for different pages, identified by their body#id (except for maybe Chat which is a bit weird with it's javascript generated page).

I had a play with converting the Choice module to Quickform for comparison purposes.

You can check it out on our Moodle, logging in with username/password both 'quickform' and see the code here:

• view.php
• mod.html

I didn't replace the forms, simply duplicated them so you'll see the normal form followed by a Quickform doppelgänger. (I also moved some code from lib.php back into view.php to make comparison easier).

Some comments:

• It's a quick hack and not everything works or looks and behaves as it should, but mostly because I just didn't get round to it. I didn't notice any showstoppers that prevented me from doing anything, and was generally quite impressed. It all seemed to 'just work' to a surprising degree.
• I turned on the HTML editor for the account given above and it appears to work as expected, but I don't really use it ever so ping me if it's acting oddly.
• I tried to refrain from changing things unrelated to the forms, but I ended up cleaning up some stuff just to check I understood what was happening, and couldn't resist the opportunity to make a couple of changes e.g. get rid of the colons after lable names and make the outputted HTML code very slightly more pleasant in some places.
• I chose Choice because it not only has a nice range of inputs including variable number of options, javascript disabling of things etc. but the actual view that students see is basically a customised form too.
• My only complaint about Quickform is that I had to read the source of the default renderer before I understood how to format a replacement template because it didn't appear to be documented anywhere.
• I didn't bother to hook up the existing javascript stuff but I assume it would just work. I had wanted to investigate Quickform or a 3rd party's javascript to make the addition of extra choices more AJAX-y but didn't get around to it.
• Another thing I might look at if I get time is passing existing Moodle form code through as HTML. So you could replace the standard stuff with Quickform and then come back later and think about how to recreate/replace the more customised elements in your own good time. I'm fairly certain this would work and reduces the already low difficulty level of incorporating Quickform from 'basically just typing' down to 'trained monkey could do it'.
• building on the previous point I think the introduction of any centralised form library is a good time to re-assess the decisions that took advantage of the opportunity to be flexible e.g. the Glossary input screen discussed earlier (also see this post for my suggestion of how that UI could be improved). I think accepting the constraints of e.g. one item per line in a vertical list has a host of benefits (accessibility, usability, moodle for mobiles, etc.) at very little cost.

I found an example of various features of Quickform taken from the documentation:

working example

source code for the example

That does a heck of a lot, including defining the layout for certain special form elements and validation but I can't say the source seems particularly frightening even including that.

Regarding fancier validation and AJAX (e.g. checking if a username is taken without a full page reload) note that unobstrusive javascript / progressive enhancement and HiJax (s5 slides)(which I think is the way to go for 'legacy' web apps, such as Moodle, that want nice AJAX effects but require accessibility) actually make it much easier to do this kind of thing since all you need to generate (within the form at least) is nice XHTML with appropriate classes.