Changes to course listings in 2.5

Changes to course listings in 2.5

Marina Glancy發表於
Number of replies: 19
Core developers的相片 Moodle HQ的相片 Moodle Workplace team的相片 Peer reviewers的相片 Plugin developers的相片 Testers的相片

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!

評比平均分數:Useful (2)
In reply to Marina Glancy

Re: Changes to course listings in 2.5

Mary Evans發表於

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.

In reply to Marina Glancy

Re: Changes to course listings in 2.5

David Scotson發表於
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?
In reply to David Scotson

Re: Changes to course listings in 2.5

Davo Smith發表於
Core developers的相片 Particularly helpful Moodlers的相片 Peer reviewers的相片 Plugin developers的相片

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
}

In reply to Davo Smith

Re: Changes to course listings in 2.5

David Scotson發表於
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.
In reply to David Scotson

Re: Changes to course listings in 2.5

Dan Poltawski發表於

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!

評比平均分數:Useful (1)
In reply to Dan Poltawski

Re: Changes to course listings in 2.5

David Scotson發表於
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.
In reply to Dan Poltawski

Re: Changes to course listings in 2.5

Gareth J Barnard發表於
Core developers的相片 Particularly helpful Moodlers的相片 Plugin developers的相片

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

In reply to Gareth J Barnard

Re: Changes to course listings in 2.5

Marina Glancy發表於
Core developers的相片 Moodle HQ的相片 Moodle Workplace team的相片 Peer reviewers的相片 Plugin developers的相片 Testers的相片

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

In reply to Marina Glancy

Re: Changes to course listings in 2.5

Tim Hunt發表於
Core developers的相片 Documentation writers的相片 Particularly helpful Moodlers的相片 Peer reviewers的相片 Plugin developers的相片

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.

In reply to Tim Hunt

Re: Changes to course listings in 2.5

Gareth J Barnard發表於
Core developers的相片 Particularly helpful Moodlers的相片 Plugin developers的相片

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

In reply to Gareth J Barnard

Re: Changes to course listings in 2.5

Tim Hunt發表於
Core developers的相片 Documentation writers的相片 Particularly helpful Moodlers的相片 Peer reviewers的相片 Plugin developers的相片

That is not what I am saying.

theme_renderer_base does not subclass core_course_commonbits_renderer.

"Prefer aggregation over inheritance."

In reply to Tim Hunt

Re: Changes to course listings in 2.5

Gareth J Barnard發表於
Core developers的相片 Particularly helpful Moodlers的相片 Plugin developers的相片

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

In reply to Gareth J Barnard

Re: Changes to course listings in 2.5

Tim Hunt發表於
Core developers的相片 Documentation writers的相片 Particularly helpful Moodlers的相片 Peer reviewers的相片 Plugin developers的相片

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.

In reply to Tim Hunt

Re: Changes to course listings in 2.5

Gareth J Barnard發表於
Core developers的相片 Particularly helpful Moodlers的相片 Plugin developers的相片

Dear Tim,

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

Kind regards,

Gareth

附件 th.png
In reply to Gareth J Barnard

Re: Changes to course listings in 2.5

Mary Evans發表於

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. 微笑

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

Don't worry be happy! cheers

 

 

評比平均分數:Useful (1)
In reply to Gareth J Barnard

Re: Changes to course listings in 2.5

Tim Hunt發表於
Core developers的相片 Documentation writers的相片 Particularly helpful Moodlers的相片 Peer reviewers的相片 Plugin developers的相片

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.

In reply to Tim Hunt

Re: Changes to course listings in 2.5

Gareth J Barnard發表於
Core developers的相片 Particularly helpful Moodlers的相片 Plugin developers的相片

Dear Tim,

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

Cheers,

Gareth

In reply to Gareth J Barnard

Re: Changes to course listings in 2.5

Mary Evans發表於

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

In reply to Mary Evans

Re: Changes to course listings in 2.5

Gareth J Barnard發表於
Core developers的相片 Particularly helpful Moodlers的相片 Plugin developers的相片

Dear Mary,

In that case, no worries or problems 微笑.  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