Future major features

 
 
Picture of Marina Glancy
Changes to course listings in 2.5
Group DevelopersGroup Moodle HQGroup Particularly helpful Moodlers

In 2.5 all html generation is moved from course/lib.php to course/renderer.php so themes can override it. Also print_section() was split into several renderer functions and course formats can use any combination of them. See MDL-36320.

Another major thing is the category/course listings. All courses/categories listings will be under course/index.php, all management - under course/manage.php. Switching between viewing and management no longer depends on global editing mode, so it's less confusing for users (see MDL-37572).

Also course/category listings will also be displayed through renderers and look consistent throughout the site. See http://docs.moodle.org/dev/View_all_courses

Suggestions are welcome!

 
Average of ratings:Useful (2)
It's only an avatar...
Re: Changes to course listings in 2.5
Group DevelopersGroup Documentation writersGroup Particularly helpful MoodlersGroup Testers

Thanks for that Marina, this looks very promising. I'll take a look and come back with some suggestions if I find something worth discussing at length.

 
Average of ratings: -
Picture of David Scotson
Re: Changes to course listings in 2.5
Group DevelopersGroup Documentation writersGroup Particularly helpful Moodlers
Regarding the HTML in course/renderer.php, I'm a bit confused about how that can be overridden by themes.

I'm currently trying to do this in 2.4, where some of the renderer functions already exist. And while I can override these functions, my version is never called because the specific course format (e.g. topics) doesn't inherit from my renderer, it inherits from the core version. How can you actually change anything in course/renderer.php and not have it overwritten by subclasses?
 
Average of ratings: -
Davo
Re: Changes to course listings in 2.5
Group DevelopersGroup Particularly helpful Moodlers

In theme/THEMENAME/config.php:

$THEME->rendererfactory = 'theme_overridden_renderer_factory';

In theme/THEMENAME/renderers.php:

require_once($CFG->dirroot.'/path/to/overridden/renderer.php');
class theme_THEMENAME_NAME_OF_OVERRIDDEN_RENDERER_CLASS extends NAME_OF_OVERRIDDEN_RENDERER_CLASS {
function name_of_function_to_override($param1, $param2) {
// Insert code here
}

So if, for example, you want to override a format renderer, you should be able to write

require_once($CFG->dirroot.'/course/format/topics/renderer.php');
class theme_mytheme_format_topics_renderer extends format_topics_renderer {
// Functions to override
}

 
Average of ratings: -
Picture of David Scotson
Re: Changes to course listings in 2.5
Group DevelopersGroup Documentation writersGroup Particularly helpful Moodlers
Sorry, it was actually course/format/renderer.php that I'm having trouble with, since that is an abstract class that is then inherited by course/format/topic/renderer.php. But when you create renderers that inheritence relationship is broken (as far as I can tell) and your topic/renderer.php always points at the core class.

Actually typing that out has suggested a solution to me, that I need to explicitly extend the theme_themename class. I'll give that a try.
 
Average of ratings: -
Dan at desk in Moodle HQ, Perth
Re: Changes to course listings in 2.5
Group DevelopersGroup Moodle Course Creator Certificate holdersGroup Moodle HQGroup Particularly helpful MoodlersGroup Testers

Hi David,

I introduced that it in 2.3 and so this is probably my fault. In fact at the time it really was just an attempt to abstract away the inline html and make the code duplication less between the core formats. I was aware that future changes were coming (and I didn't have much time for it in 2.3) so I tried to explain that in the comments https://github.com/moodle/moodle/commit/a8f02a346243f56417c7cc08ecb3bfd92d881f7d that it wasn't a real renderer (only half way step), but re-reading, it seems I didn't do a very good job!

 
Average of ratings:Useful (1)
Picture of David Scotson
Re: Changes to course listings in 2.5
Group DevelopersGroup Documentation writersGroup Particularly helpful Moodlers
It's not a big problem, I just wasn't sure if I was doing it right, I'd spent a day wondering why some other course renderer stuff wasn't working and eventually realised I'd missed "theme" off the start of the class name so I was beginning to doubt myself.
 
Average of ratings: -
Gareth J Barnard
Re: Changes to course listings in 2.5
Group DevelopersGroup Particularly helpful Moodlers

Hi,

I actually think Dan did a good job with '/course/format/renderer.php' despite my initial 'panic mode on, need to support this and users are protesting' issue.  It makes it a easier for me to support core changes automatically as I only over ride what I need to in the course format.

I think that the confusion comes from the fact that '/course/renderer.php' renders the components of the course which are overrideable by the theme, but it is the course format that defines the layout and as little styling as possible by overriding '/course/format/renderer.php'.  Themes and course format's share a common goal but do need to be separate because theme's style and perform overall layout, course format's just layout courses because you always want a 'corporate image' and way of doing things across all courses but want at the same time to have separate layout templates for the individual courses.

I hope this makes sence!

Cheers,

Gareth

 
Average of ratings: -
Picture of Marina Glancy
Re: Changes to course listings in 2.5
Group DevelopersGroup Moodle HQGroup Particularly helpful Moodlers

Gareth,

if theme can not override format_topics_renderer because of the extra parent, it is a serious problem. And if it is the case we need to raise a tracker issue for that and move discussion there. I have not tried it myself yet so I can't confirm at the moment.

The solution that I see is to make the format_section_renderer_base not abstract and other renderers such as format_topics_renderer will do $this->baserenderer = $this->page->get_renderer(...) in their constructor and instead of calling parent::xxx() will do $this->baserenderer->xxx().

And format_section_renderer_base::section_edit_controls() can be moved to format_base class. Actually I should have done it in 2.4 when I created format_base class. I only moved is_section_current() at that moment

 
Average of ratings: -
Tim at Lone Pine Koala Sanctuary
Re: Changes to course listings in 2.5
Group DevelopersGroup Documentation writersGroup Particularly helpful Moodlers

No, that is not a solution. Do not mix up base classes and helper classes like that.

There should still be an abstract base class format_renderer_base, and all specific renderers like format_topics_renderer should be

class format_topics_renderer extends format_renderer_base {

and use parent:: like normal. Doing anything else leads to insanity.

When you have some common code that needs to be shared between different format renderers, but still overridable, don't put it in format_renderer_base. You need a new renderer

class core_course_commonbits_renderer extends plugin_renderer_base {

format_renderer_base, format_topics_renderer and similar classes will use methods of the course_commonbits_renderer to output shared stuff.

 
Average of ratings: -
Gareth J Barnard
Re: Changes to course listings in 2.5
Group DevelopersGroup Particularly helpful Moodlers

Dear Marina and Tim,

I could be wrong about my assumption as it's how I perceive things at the moment from a functional design point of view.

I agree with Tim with the format_renderer_base still being abstract.

Understanding this from an OO / Java / C++ background perspective I would think that the theme would want to override certain functionality and a course format another.  If you have the structure:

format_renderer_base -> format_renderer_course_format_overrides -> format_renderer_theme_overrides

Because the theme wants to override some of what the course format is doing then you would need a class for each course format you wanted to support unless PHP supports multiple inheritence (nasty).

But as I understand it with what Tim is saying you would have:

plugin_renderer_base -> core_course_commonbits_renderer(abstract) -> format_renderer_base(abstract) -> format_renderer_course_format_overrides

and

plugin_renderer_base -> core_course_commonbits_renderer(abstract) -> theme_renderer_base(abstract) -> theme_renderer_theme_overrides

Such that the theme and the course format can perform overrides.  But what happens when there is a conflict?  Should themes and course formats do the same thing or should there be a distinction in functionality of responsibility?  Such that a theme does specific things and a course format does other specific things and never the twain shall meet.

Cheers,

Gareth

 
Average of ratings: -
Tim at Lone Pine Koala Sanctuary
Re: Changes to course listings in 2.5
Group DevelopersGroup Documentation writersGroup Particularly helpful Moodlers

That is not what I am saying.

theme_renderer_base does not subclass core_course_commonbits_renderer.

"Prefer aggregation over inheritance."

 
Average of ratings: -
Gareth J Barnard
Re: Changes to course listings in 2.5
Group DevelopersGroup Particularly helpful Moodlers

Dear Tim,

So if both the theme and the course format both aggregate core_course_commonbits_renderer in their abstract base classes how does the theme override any method that the course format does?

Cheers,

Gareth

 
Average of ratings: -
Tim at Lone Pine Koala Sanctuary
Re: Changes to course listings in 2.5
Group DevelopersGroup Documentation writersGroup Particularly helpful Moodlers

I am wondering what sort of OO / Java / C++ knowledge you acutally have. You are not understanding what I say, and I am not in the mood to explain at greater length now.

 
Average of ratings: -
Gareth J Barnard
Re: Changes to course listings in 2.5
Group DevelopersGroup Particularly helpful Moodlers

Dear Tim,

Perhaps I am not explaining myself, so I have drawn a class digram - attached.

Kind regards,

Gareth


 
Average of ratings: -
It's only an avatar...
Re: Changes to course listings in 2.5
Group DevelopersGroup Documentation writersGroup Particularly helpful MoodlersGroup Testers

The only way to keep this discussion from going belly up is to do what Marina says and test the course format renderers, and if they are found to be flawed then file it as a BUG in Moodle Tracker.

I'm too tired to read, and not knowledgeable enough about renderers to comment, although I have discovered a wonderful way to include plugin renderers in themes thanks to Tim, so I guess he knows what he is talking about. smile

Have a nice weekend everyone. Please don't spend it renderers! bah humbug!

Don't worry be happy! cheers

 

 

 
Average of ratings:Useful (1)
Tim at Lone Pine Koala Sanctuary
Re: Changes to course listings in 2.5
Group DevelopersGroup Documentation writersGroup Particularly helpful Moodlers

Well, they say a picture is worth 1000 words, and your picture certainly qualifies. It is exactly right. Sorry I failed to understand what you were saying before.

 
Average of ratings: -
Gareth J Barnard
Re: Changes to course listings in 2.5
Group DevelopersGroup Particularly helpful Moodlers

Dear Tim,

No worries smile - just goes to show why class, object interaction, state transition diagrams... exist to describe the form and function of software.

Cheers,

Gareth

 
Average of ratings: -
It's only an avatar...
Re: Changes to course listings in 2.5
Group DevelopersGroup Documentation writersGroup Particularly helpful MoodlersGroup Testers

Dear Gareth,

What theme designers want to do is to get everything in Moodle to look the same, which, in some cases, means changing the css selectors too. I don't think for a minute they want to change the way a Course Format works, but more in the way it looks on the page.

Mary

 
Average of ratings: -
Gareth J Barnard
Re: Changes to course listings in 2.5
Group DevelopersGroup Particularly helpful Moodlers

Dear Mary,

In that case, no worries or problems smile.  It's up to course format developers to ensure their css is unique to them and does as little as possible in terms of stying.  I fell foul of this by setting the font size of the section name and had to do a fix.

Thanks,

Gareth

 
Average of ratings: -