Martin Dougiamas

Brian Jorgensen from Athabasca Uni gave a very insightful and entertaining presentation about this topic at the Canadian Moot earlier this year:

http://www.slideshare.net/moosetrout/ranching-killer-zombie-robots-lessons-learned

Hi all,

We'd really love your help to review the plan for a rather significant revamp of the resource module for Moodle 2.0.

Please see http://moodle.org/mod/forum/discuss.php?d=125824 and discuss there.

Cheers!

Following on from the complete rewrite of file handling in Moodle 2.0 (see File API and Repository API docs), we need to rewrite the resource module to:

• take advantage of the new File features and
• improve security and portability of resources

This document outlines the current plan: Resource module file API migration

The first major thing you will notice is that the current single resource module (with various subtypes) is being broken apart into several full modules: resource, page, url, folder and imscp.

I know this will seem like a rather extreme change, but I think the rationale is there, and a major release like Moodle 2.0 is the time to do it.

We would love your feedback about this plan and your help in thinking about it. Please read the document carefully and reply here with any thoughts you have about it (or start new discussions in this forum).

Well, here is the story.

A long time ago (almost three years!!!) we had to decide on one of these, and after some discussion (this one!) the consensus at that time was clesrly for Feedback to be standard (note that carrying both modules in core is simply not an option).

Feedback had enough features and an interface people liked plus cleaner, more Moodley code that programmers liked (to ensure people built more in future).

Questionnaire was a bit of a Frankenstein module at the time with an awkward interface borne of it being built around PhpESP.

So finally Feedback got into core over a year ago (where it is now) awaiting the next release. It's working fine there, just needing a few tweaks to polish it up (in my opinion). Everyone knew this was now a core module, and there is a 1.9 version that can be used now, with no fear of losing data in an upgrade to 2.0 later.

Meanwhile, development continued heavily on Questionnaire. (This makes me a little sad because I would love to have seen that effort going into the one we'd chosen here instead).

Questionnaire is now a lot more Moodley and usable. However, I just had a quick skim and still see some problems, such as non-strict XHTML (hard-coded styles, tables for layout), all the questiontypes being crammed into one file instead of being pluggable, no inline documentation etc. So it's not perfect, and needs quite a bit work to review it properly and polish it up for 2.0.

If we switched to Questionnaire now it would

- upset a lot of people who had counted on Feedback being standard
- be quite a lot of extra work, with more cost and more delays to 2.0

I would do it if there was an OVERWHELMING vote to do this, but otherwise it just doesn't seem to be fair.

I would much rather see a clear analysis/specification of the bugs and missing features from Feedback so we can direct some effort into improving that module.

Hi Urs,

Definitely themes are for themers, of course.

To me, the example header.php you give above is actually a perfect example of programming code that has almost nothing to do with the appearance of the theme. Moodle code does most of the hard work here by inserting data via the hooks into a strrrrict structure. The majority of theme designers don't need to change any of these things, they just need to be able to easily specify what css and javascript files they want to add.

I think it makes sense to make this part a PHP function. Of course advanced themers can still easily override that function if they really want to, inserting all the extra logic they need. And of course the "standardtemplate" theme can provide a header.html file in your format to do the job.

eg something like:

class standardtemplatetheme extends coretheme {
function print_header() {
global $PAGE;

include($PAGE->themeroot.'/templates/header.html');
}
}


I know Tim *is* thinking about simplifying the work required for a themer, and ALSO thinking about long-term maintenance. I can't remember how many times in the past I had to go through all the themes (core and contrib) updating the rather flaky header.html and footer.html to add/remove/fix changes happening in core. It was quite a lot.

However, thinking from a themer point of view I often wanted to insert HTML inside the BODY tags at the top or bottom, and I think that's very common. Too common to make themers edit PHP functions.

Do we need a standard bodyheader.html and bodyfooter.html to achieve this? Or is this enough of a reason to keep header.php and footer.php for the whole lot?