Future major features

Element Library

This discussion has been locked because a year has elapsed since the last post. Please start a new discussion topic.
Tim at Lone Pine Koala Sanctuary
Re: Element Library
Group Core developersGroup Documentation writersGroup Particularly helpful MoodlersGroup Plugin developers

Let me try to summarise (in a short post wink) some of the things that have been said about one of the key issues:

Should we pass 'real' objects to renderers, or specially made renderables objects that only contain the information needed for output?

As Damyon/Sam said in the spec: "... This means that the renderable class [a real object] can be a mixture of data and methods that perform logic associated with the module. This also means that the renderer can call those methods on the renderable class - effectively using the API of the module."

Certainly, calling a method on an object that has been passed into the renderer is one of the more subtle ways to sneak logic into a renderer, and that is bad. However, I think the general assumption in Moodle is that developers are non-malicious. If you want people not to do something, then it is normally enough to just ask them nicely (in the coding guidelines) and then check it in peer review and integration review. After all, any developer could add a call to undefined_function() in there renderer and crash Moodle. That is far worse than sneaking logic into a renderer, but it does not happen and we don't try to prevent it. (Of course, logic in renderers does happen sad )

However, there are plenty of methods on objects that would be fine to call in a renderer. The best example I can think of is the context object, and the methods $context->get_context_name() and $context->get_url(). Those would be completely fine to call in a renderer. So, I think this line of code is fine. (However, a lot of the other code in that renderer does not belong there!)

An advantage of using methods like this is that it means we do not compute something (e.g. the URL or the context name) unless we actually need it. This is like lazy evaluation, and is good. It is like the LISP/Scheme notion of a 'thunk'. In PHP a logically side-effect-free method of an object (which you can hide behind a PHP magic method if you like) is the simplest way to achieve this.

The other key point is Fred's, that using real objects give more flexibility to themes. For example don't have separate link and button renderables. The concept here is an action, so the element should be an action, and it is up to the theme whether it should be a link or a button. (Of course, the action needs enough meta-data, such as whether it is a GET or POST request, to help the theme render it appropriately.)

Another good example would be user picture. Sadly, we don't (yet) have a a real user object in Moodle. Perhaps we should, in the same way that $context stdClasses were converted to be real context classes. When a forum wants to output the information about who made the post, as part of rendering that post, then the current way is to call the user_picture renderer. However, what it really wants is to display information about the user in a particular amount of space. It would be more flexible if the theme could decide how to do that. The default is the picture with the name beside it, but why should the theme be limited to that?

(Of course, for consistency, a theme would want to change how users are shown everywhere, not just in forum posts, if it was changing this.)

Oh dear, I seem to have failed to do what I promised. This post is not short, and I spent more time giving my own opinions than summarising what others said.

Since this is already long, let me finish with one anecdote about passing limited data to templates.

One time I wanted to modify the output of CVSweb. The screen I wanted to customise was the one that showed the diff between two versions of the file. It showed useful information about one of the files, but not the other. I wanted to add the missing information. CVSweb uses templates, but it just passes to the template the values it thinks it needs. So, more like the renderable idea than the real object idea. Since it did not pass the two file objects to the template, the only way to get the information I needed was to change the code that called the template, as well as the template itself. Hence, there was no benefit to this system using templates. I hope we do better.

Average of ratings: -