Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

Snapshot - flat HTML export of complete course: Difference between revisions

From MoodleDocs
No edit summary
No edit summary
Line 14: Line 14:


In organisational terms the main script will probably live in the course subdirectory accepting the course id as its input parameter. This script will be responsible for handling the enclosing zip file and generating the course page contents. Every module will have an optional method added to its library to handle this functionality. This function will generate the HTML snapshot for a particular instance of the module. If the module does not participate (i.e., does not implement the function) its entry in the course page will not be a clickable link and its contents will not be included.
In organisational terms the main script will probably live in the course subdirectory accepting the course id as its input parameter. This script will be responsible for handling the enclosing zip file and generating the course page contents. Every module will have an optional method added to its library to handle this functionality. This function will generate the HTML snapshot for a particular instance of the module. If the module does not participate (i.e., does not implement the function) its entry in the course page will not be a clickable link and its contents will not be included.
==Detailed Implementation==


==Issues to be resolved==
==Issues to be resolved==

Revision as of 10:42, 22 October 2007

Motivation

If you want to retain a completed Moodle course for future reference the only way, currently, to keep it visible is to leave it in place on a Moodle site. If the institution has a policy of having course material available to students for a number of years (as is often the case) this can effectively multiply the number of Moodle courses by a factor of as much as five or six. As Moodle has no concept of versions of a course this, at best, adds to the clutter and confusion for students. At worst it may impose a serious performance and resources problem for the site.

There is really no requirement for these courses to remain active in the sense that interactive portions of the course still operate. In fact it is actually a benefit that the interactive activities in archived courses are *not* operational (ie, are read only).

This proposal, therefore, is to explore a system for generating "flat" HTML files of a course at a particular point in time. This could typically be at the end of a course when the active Moodle course is removed but the snapshot will remain available in an archive area. There are other benefits; the code to generate HTML representations of each activity is likely to have other applications, e.g., material for ePortfolio inclusion. Indeed, it would be relatively straightforward to include on the bottom of each activity page a "Portfolio this" button (although I'm sure there's a better name out there)

Technical Overview

The basic idea is that the user will click the Snapshot button (probably) in the Course Administration menu and this will generate a zip file containing a set of HTML pages and files. The representation of the course page will be the index.html file. Each resource or activity will have its own HTML page (or pages where required). The course files will be copied into the zip file as required.

The intention is that the output HTML will be fairly lightweight (in comparison to the normal screen output), have abundant CSS identifiers and be styled by an included CSS page. It is not currently envisioned that additional features like blocks be included although some provision could be added to the API for blocks that wish to participate.

In organisational terms the main script will probably live in the course subdirectory accepting the course id as its input parameter. This script will be responsible for handling the enclosing zip file and generating the course page contents. Every module will have an optional method added to its library to handle this functionality. This function will generate the HTML snapshot for a particular instance of the module. If the module does not participate (i.e., does not implement the function) its entry in the course page will not be a clickable link and its contents will not be included.

Detailed Implementation

Issues to be resolved

Who can use this/Performance

This could turn out to be a fairly intensive process performance wise which may be an issue if it is available to all comers. The simplest solution is to simply make its available a permission in the roles infrastructure which is not available to students by default.

As, by definition, it generates a zip file it would need to be decided if that zip files persists after it has been downloaded. If so part of the cron structure could remove old files but this is probably starting to involve creating an options page.

Variable student views

Students can, most due to groups, have entirely different views on the contents of a course. In fact, this may even involve serious confidentiality implications. It is easy enough to allow a student the simply grab 'their' view of the current course. Similarly, it is easy enough for a teacher to grab a snapshot of the entire course with all groups included. However, it is much less obvious how a teacher could take a snapshot intended to be viewed by all students in all groups. Perhaps this is simply not possible and the tool would be ineffective in this mode.

How to link to ePortfolio options

Moodle currently has no standard portfolio module and there are a number out there. As has been described earlier, it would be very nice to be able to add Moodle content (for example the current view of a forum discussion) to a portfolio as a snapshot. As the library function in the modules more-or-less does exactly what is required this should be an easy add on. What is less clear is how to interface, in the general case, with external options. A published API would clearly be needed. This would likely require some sort of "callback" arrangement, where the portfolio system (or anything else that wants to do this) would "register" its interest.