David Scotson

Do other similar systems in PHP really just write plain HTML into their code? How is it possible for them to maintain consistency? Is that all done manually within the theme?

Just had a look at Wordpress, they seem to have a mix of templates that call functions from a standard API and functions that embed the HTML directly. The functions are overridden by themes. Then they also have the shortcode system to embed functions into content.

One pattern I see is that they use quite "programmery" things to to generate the list of classnames, then just insert the result in as text e.g.:

$css_class = implode( ' ', apply_filters( 'page_css_class', $css_class, $page, $depth, $args, $current_page ) );

$output .= $indent . '' . $link_before . apply_filters( 'the_title', $page->post_title, $page->ID ) . $link_after . '';

from: https://github.com/WordPress/WordPress/blob/master/wp-includes/post-template.php

I'd kind of been working on the principle that if you could cope with imploding filtered arrays then you'd be happy enough calling a function to generate the HTML. But maybe people just ignore the scarier bits and change the stuff they recognise?

I think I had actually seen that function. I skimmed through the class as I was writing a replacement for it as even though I didn't like the API and/or wanted to have tests that I could run independently to allow me to reshape the API as I went, the functionality required was documented there.

That version takes a moodle_url. A grep for the 17 uses of this function in Moodle reveals 2 of those are creating a moodle_url from an array just so that the array can be pulled back out of the object by that function. My version just takes a plain PHP array. There's also no single hidden input version, in which case you'd need to create a single item array as well as a moodle_url object to use this version. I would consider this code below to be as confusing as the code quoted above though for different reasons. It's misleading about what's going on as it would appear on first reading that a moodle_url is required by the function and that $PAGE->url was going to be used in some way, and who knows what kind of exciting things could be happening in the moodle_url constructor:

 

echo html_writer::input_hidden_params(new moodle_url($PAGE->url, array('sesskey' => sesskey(), 'return' => $return)));

 

Arrays are probably the best bit of PHP, using them for params is almost a perfect match. Passing a moodle_url into something that was creating the whole form on the other hand, and was going to use both the url and the parameters makes more sense.

But my point was more that code in this style wasn't being used, the fact that a library function exists and it is still not being widely used isn't exactly an improvement for anyone reading that code.

An actual example that I've found in various renderers:

foreach ($nextstageurl->params() as $key=>$value) {
            $form .= html_writer::empty_tag('input', array('type'=>'hidden', 'name'=>$key, 'value'=>$value));
        }

Where the code is basically a verbose version of the output HTML:

<input name=contextid type=hidden value=2>
<input name=filepath type=hidden value=318aeb66dba730135ab93ba66f9dbea3>
<input name=stage type=hidden value=2>

And could have probably just as easily been written:

foreach ($nextstageurl->params() as $key=>$value) {
            $form .= "<input type=hidden name=\"$key\" value=\"$value\">";
        }

But since we've already introduced the PHP function and the concept of looping, and hidden inputs are fairly standard things I'd rather see:

html::hidden_inputs($nextstageurl->params());

or for a single input:

html::hidden_input($name, $value);

even though it might initially be a bit more opaque, it's much more readable once you understand it, and you can get a much better overview of what's going on rather than everything being hidden by the low-level details. And then you can get even more abstract and just pass the params into the function building the form, or just pass the moodle_url object that actually has both the URL and the params within it rather than extracting them out and working on them directly every time.

There is a script for this but it was slightly broken the last time I tried it so only certain parts worked. Have a look at:

http://yourmoodle/admin/tool/generator/index.php

or via the command line: admin/tool/generator/cli/generate.php

If you want to help test then the best thing at the moment is to install this theme and visit sections of Moodle you know well, preferably with content you know well and report anything that is totally broken.

https://github.com/ds125v/moodle-theme_bootstrap_renderers

By totally broken I don't mean a checkbox being in slightly the wrong place, but rather a checkbox not being visible at all, or being unable to click it on and off, things of that magnitude. But if it occurs on the main page of the site or course then I'm probably already aware of it, things inside activities and resources are of most interest at the moment.