Urs Hunkler

Chris, great that you think the »cleanm« theme is a good and understandable example to work with. The work I have investigated seams to help others.

»cleanm« works with renderables and renderers. For example »class columns3_layout extends base_layout implements renderable, templatable«.

With the Moodle docs I find myself often in the same situation - abstract descriptions of complex topics which are difficult to understand without examples. The cookbook approach is much more helpful for me in many cases. I learned about the Moodle Mustache implementation much more while looking and analyzing Damyon's »learningpath« template example in his Git repository than by reading the docs.

The »partial« subdirectory I have created to save all »dynamic partials« which had been loaded with a »dynamic partial helper« in the first implementation. Damyon proposed to render the »partials« within the renderables without a »dynamic partial helper«. I had proposed to add the »dynamic partial helper« to Moodle core because I think it makes definitely sense when working with templates. But I never have gotten an answer and Moodle 2.9 shipped without a »dynamic partial helper«.

By the way - why do you think the partials subdirectory is an issue? Technically is doesn't matter if you save the templates flat or in an organized subdirectory structure. I prefer the organizational subdirectory structure to offer e better overview. 

In the analog world if it may no longer be possible to modernize an old building the building gets torn down and rebuild from scratch. Or it is kept as a museum and the inhabitants move on into a new building somewhere else. In the digital world this is also an option.

Gareth - with »The inconsistent Moodle interface codebase« I meant the user intrerface - the HTML pages - Moodle displays in the browser, not class/object interfaces in code.

Gareth, I wanted to tell my opinion and the basic underlying insight is that Moodle core needs to be changed. The approach to conceal the base issue by adding coverings should be recognized and stopped.

In point 1.) is implicitly contained the modular approach you mention. You may guess that I don't propose to use a »late 90's Windows 95 web browser« look as the base style for Moodle.

For me the situation we face now is worse than an approach where the Moodle user interface bases on Bootstrap. The advantage of easy and consistent styling with a set of predefined hooks counts. If the decision may be to relay on Bootstrap I'm fine - it's better than what we have now.

After a bit more thinking my opinion about Moodle and Bootstrap is

1. Either remove Bootstrap from core.
   
2. Or fully integrate it (means use Bootstrap hooks everywhere in templates and renderers).

Simey's description »This might not be an easy and fast upgrade and certainly would cause regressions.« and »the upgrade to bootstrap 2 was painful and full of regression« is the evidence that hacking Bootstrap onto the actual Moodle codebase should not be the way to go. So the only ways out seam either 1 or 2.

The inconsistent Moodle interface codebase is the problem - not Bootstrap. And this problem needs to be solved. I recommend to start working with a Moodle Element Library as a development/design tool and not to see it as a theme designer's showcase when everything is ready.

To me it would be ok to build Moodle interfaces based on Bootstrap. It would be a dream to be able to add a class to an element and have them look the same everywhere in Moodle. And with templates it would not be that difficult to upgrade a core Bootstrap implementation.