Future major features

Element Library

Tim at Lone Pine Koala Sanctuary
Re: Element Library
Core developersDocumentation writersParticularly helpful MoodlersPlugin developers

I finally made time to read the latest version of the spec.

I have only got half way so far, but most of what I have read so far has been really good. I have to go to an orchestra rehearsal now, so expect more comments later.

Project Goals & Benefits

I think you have done a really good job at the top of http://docs.moodle.org/dev/Render_library_specification of distilling the essential goals of this project down to a few short bullet points. Hopefully this pays us all back by keeping the (huge amount of) work focussed.

So what is the problem

I disagree with the "We have no established best practices". Three-layer archtecture, separating UI, logic, and persistence, is a well established pattern, and renderers are Moodle's way of doing that separation of the output code from the logic. So, lots of software design best practice does apply, and is applied, by many Moodle developers. I am prepared to accept your statement that this is insufficiently documented.

"Developers are encouraged to push functionality boundaries in order to take it places observed in other projects or to challenge oneself." I think this is unfair. At least in the quiz, where I have gone for a design that is not a copy of something somewhere else in Moodle, that is becuase I have been trying to develop the best UI I can for that bit of functionality. Functionality that users need.

I don't think this list curretnly puts the most important things first. E.g. "Themers have a mammoth task ..." is much more important than lack of dev docs. (The order only matters in that it makes the document more readable to get to the importnat points first.)

The elephant in the room

Suddently, when we get to the "Element library and style guide" section, it is taken as read that Elements will be rendeables: "Establish a definition method of elements, and compositions of elements as renderables."

This is certainly not a given. If you think we muse use renderables everywhere (that is, for any thing that you want to output, you have to define a PHP class) then that is something that you need to justify carefully. I am not convinced. I will probably post more on this point when I have read the whole spec.
Thoughts on naming

From private chat with you, I know none of us are big fans of all the Atomic design terms. Particularly 'organism'. However, it is something of a standard, so I think we should just grimace and use the standard terms.

Style guide

I was wondering if it was really neceassry to have a separate style-guilde, or whether we could get everything we want from the Element library. However, I see that the propose style guide is at a higher, more meta, level than the element library, and something there probably is necessary. However, it should be kept as a short statement of principles, and should not duplicate the kind of information that is embodies in the element library.

... this is as far as I got in my reading just now.

Minor quibbles from earlier in the document.

In "Understanding renderers in Moodle"

"Renderers were introduced in a time before Object Orientation was used in Moodle" - this is not true. There was lots of object orientation in Moodle when we introduced renderers. I more accurate sentence would be "Renderers were introduced at a time when we were starting to greatly increase the user of Object Orientation was in Moodle core."

At the end of that paragraph, I would be inclined to add the sentence "Renderers were the closest thing to templates that it was possible to implement in Moodle at the time."

More history

For anyone wanting more of the history, renderers were originally a concept I came up with, in response to demands to let people override the design of Moodle with templates. See MDL-19077. Looks like the original spec was delete from the dev docs, because it was obsolete.

I worked on them while I was at Moodle HQ, in the first half of 2009. Nico also helped. Then I went back to the OU, passing the baton to Sam Hemelryk, who had recently started at Moodle. (What a baptism of fire!)

Later, towards the end of 2009, Petr Skoda had a big hand in improving the concept, particularly at the themes end of the system. See https://moodle.org/mod/forum/discuss.php?d=140089.

David Mudrak was also important, becuase in rewriting the Workshop module he was one of the early adopters of renderers, which helped shape and validate the design.

So, those are the people who deserve the praise/blame for renderers.

Average of ratings: Useful (1)