Moodle development traffic 16/2010
Latest stable version 1.9.8+
There were 12 patches committed into to the stable branch during the last development week. Helen Foster once again reworded the help describing the behaviour of a recently added gradebook feature as Elena Ivanova suggested (MDL-21218). Pasi Häkkinen discovered a malicious incorrect usage of HTML entity that led to Flash version detection being done by AJAX call at every page load instead of once per session and Petr Škoda promptly committed Pasi’s patch (MDL-22154). Dan Marsden backported Vlas Voloshin’s patch fixing the display format of exhibit time periods in SCORM 2004 packages (MDL-18835) and fixed yet another issue with First Access and Last Access dates in SCOs (MDL-16184, MDL-21423). Sam Marshall fixed a bug producing empty links when there was no group picture. Such empty links created an invisible tabstop which is confusing for screenreader and other keyboard users (MDL-22174). Tim Hunt backported some parts of unit test failure display improvements (MDL-22174). Eloy Lafuente fixed a bug in backup/restore machinery so the manually added links to the course main page are transformed into new URL, reported and tested by Larry Elchuck (MDL-22176). Petr Škoda committed a patch provided by Gordon Bridge. That fixed a bug in the Assignment module which overwrote the grade item identifier in the Gradebook with a number (column “id” of the Assignment module instance in course_modules) instead of the value defined for the activity in modedit form (column “idnumber” in that table). This critical bug had been reported before but could not be reproduced until Gordon described it in details and found the nasty line (MDL-22181).
Unstable development version 2.0dev
There are 141 commits into the main development branch last week. To highlight one, Eloy Lafuente merged first parts of the new backup/restore backend he was working on in a separate git repository recently. Sam Hemelryk is going to work on the backup/restore user interface. As many other parts of Moodle 2.0, backup/restore subsystem will be fully implemented during the beta period (which starts in six days!). The last huge change that is going to land before the feature freeze next week is Petr Škoda’s new baby – the reimplementation of enrolment plugins. After that, Moodle 2.0 APIs and database structures should be considered more or less stabilised and the team will focus on fixing the regressions only.
Quotes of the week
“That github interface is very nice”
– Martin Dougiamas after reviewing a patchset before it was committed into the main CVS repository
“Would be nice if core developers actually tried to run the code before they commit it into the repository.”
– David Mudrak gives a hint on how to prevent the most obvious bugs
“Whoa, that was quick!”
– Pasi Häkkinen found his bug fixed in 57 minutes after it had been reported
I am, YUI
All modern web applications use advanced JavaScript based techniques to increase the usability of the user interface. Things like inline editing, re-populating the parts of the page via AJAX calls or saving the forms without reloading the whole page are quite common for users today. To ease the integration of JavaScript and skip fiddling about with its different implementation in various browsers and their versions, web projects use some JavaScript frameworks like jQuery, Dojo Toolkit or YUI. The latter one, Yahoo! User Interface library, has been chosen as the official JavaScript framework for Moodle since long time ago. Moodle 2.0 ships with the most recent version YUI 3.1.0 while still providing a way how to use some widgets from earlier 2.8.0 version.
Moodle core does a lot of work for you behind the scene with including YUI libraries and their dependencies in correct location of HTML produced by your code. The most straightforward way to include JavaScript on your page is to define the code in the file module.js in your plugin directory. To avoid collisions of global variables and functions, all your code is supposed to be wrapped in a namespace. Since 2.0, we put all Moodle JavaScript code into a global M object and plugins are expected to use their own M.plugintype_pluginname namespace. For example if you write an activity module called foobar, all your JavaScript functions should be defined in M.mod_foobar namespace.
To include your code at the page and to initialize it from PHP, use $PAGE->requires->js_init_call(), providing the name of the initial JavaScript function as the first parameter. This initialization function must accept YUI instance object as the first parameter which we call Y, as is common in YUI 3. Once you have YUI instance, you can do whatever magic this library offers to you, including the possibility to load additional YUI modules with Y.use(). The ‘Hello world’ example of using YUI in Moodle 2.0 could look like this:
Let us say you are working on FooBar activity module. In your PHP script, for example /mod/foobar/view.php, add a line
$PAGE->requires->js_init_call('M.mod_foobar.init');
Then create the file /mod/foobar/module.js with the following contents
/**
* @namespace
*/
M.mod_foobar = M.mod_foobar || {};
/**
* This function is initialized from PHP
*
* @param {Object} Y YUI instance
*/
M.mod_foobar.init = function(Y) {
alert('Hello world');
}
Or, instead of just displaying the alert, to modify the current HTML code (for example to add some elements via JavaScript or to remove some non-JS support code) just use
M.mod_foobar.init = function(Y) {
Y.one('#mycustomholder').set('innerHTML', 'Hello world');
}
See YUI 3 documentation for more great examples. You may also find this blog post useful (I did, thanks Eloy for the link).
Post scriptum
I love xkcd.
I need a bigger monitor”
”
