Thank you for your reply Joby.

In my ‘MHQ proposed architecture diagram’ Boost has the Bootstrap V4 framework as an embedded attribute and Classic / Fordson inherits from it rather than the OO way of having Bootstrap V4 as a separate entity that Boost inherits from (as shown on my proposed architecture diagram). Thus with ‘In fact even back when Boost was announced I had expected that it would extend a new Bootstrap 4 base theme.’ then unfortunately it does not.

And exactly with ‘counter-intuitive that to achieve a theme without the opinionated UI of Boost’, I don’t want to have a theme that inherits from Boost and gets the baggage.

I things stay the way they are, then as a fallback there could be a way for a theme to ‘cherry pick’ elements from Boost to get the framework only but harder to do.

Thanks for the article. Terrifying swan! As you know I’m also a software developer who has been working with Moodle for a number of years. Like you, based on general software engineering principles my assumption was that the theme hierarchy in 3.6 would reflect your proposed diagram above (although I’m not 100% sure I follow your MHQ proposed architecture diagram). In fact even back when Boost was announced I had expected that it would extend a new Bootstrap 4 base theme.

Further to the issue around including Bootstrap 4 and its tight-coupling to Boost it seems counter-intuitive that to achieve a theme without the opinionated UI of Boost (e.g. because you want to implement a highly custom theme for a client) the approach is to take Boost and suppress all the additional features which it adds when compared to Classic. This is conceptually opposite to how inheritance generally works in OO programming.

Having mentored colleagues starting out with Moodle over the years I’ve found that architectural choices and APIs which do not appear to follow expected conventions also lead to frustration and disenchantment. I suspect there may well be more strategic long-term reasons for Classic inheriting from Boost but from the perspective down in the trenches it can look a bit like a kludge to save API changes to Boost which may not be feasible at this time.

Thanks Stuart,

Now that you mention about the dashboard, I realise that I’ve never thought of it that way! Is there an MDL tracker to change it back to ‘Home’ etc? If so then there should be and get some votes!

Gareth

Hi Richard,

With respect with ‘Encapsulation’ in this context you are 100% wrong. Encapsulation in object orientated computing is about hiding things in classes (object templates) so that they are hidden and protected from the rest of the program. But you’re describing it in a human context pertaining to the decision that is made upon which licence to use, open source or otherwise. So, yes the information is ‘hidden’ but from the rest of the program not any human reading / using it.

So I totally disagree. I’m not choosing encapsulation over abstraction, in fact that is an incorrect interpretation. My concept utilises encapsulation as a facilitator to greater abstraction by placing the functionality in the places it should be and having an ‘abstract’ base ‘entity’ that is the framework that requires another entity before it becomes the ‘theme’.

Therefore your interpretation is actually confusing, and with respect, will make things less clear and much more confusing for readers and therefore does not help to clear things up but rather the opposite.

Gareth

Hey Stu, yes, we’ve talked about arbitrary changes before (like Home to Dashboard) – really annoying for trainers. I see that in 3.4 or 3.5 the method of selecting enrolled users was changed and, as far as I can see, for no reason other than someone, somewhere could.

I would really, really like a moratorium on changes to Moodle for say, one year, so core developers could just sit down and tidy up all the anomalies that have crept in over the years, both in the UI and in the core code.

From the user point of view, such changes are frustrating and lead to dis-enchantment (as I have seen in a few organisations recently).

From the developer point of view, Mustache is a favoured technology now but you won’t find it used consistently in core activity modules and core blocks and you will find coding standards vary as well. These variations are a barrier to entry for would-be developers.

Encapsulation is hiding information about the function of a thing (in this case a theme).

Abstraction is a design process by which you identify what the key features of a thing (theme) should be.

So to phrase the question in another way, is it the business of Moodle Core Developers to hide away the details of the theme implementation where they are difficult to get at or is it their business to decide what the overall user interface (ie theme) should look like? This also raises the question of direction of an open source project. Moodle is built by many contributors and, one would assume, this is to the benefit of users everywhere.

Choosing encapsulation over abstraction is moving the needle away from open source and towards proprietary, would you agree? This will make life more difficult for third-party developers. Is Moodle now too big to care about those?

Like yours, mine is just a view and is, perhaps, mis-informed but I too would welcome debate that may, or may not reach the ears of those with influence.