Note:

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

Mahara Portfolio Plugin

From MoodleDocs
Revision as of 10:56, 20 July 2008 by Penny Leach (talk | contribs) (New page: ===Initial communication between Moodle and Mahara=== After the user has chosen 'Mahara' and clicked on an export to portfolio button, the first step that gets control passed to the plugi...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Initial communication between Moodle and Mahara

After the user has chosen 'Mahara' and clicked on an export to portfolio button, the first step that gets control passed to the plugin is the steal_control function, before process_stage_config is called.

At this point, Moodle should attempt to communicate an 'intent to transfer' to Mahara, giving it the necessary information about the user. Mahara at this point should create the user account if necessary. Mahara will send back one of three things - no, queue only, or queue and immediate. This is to indicate whether the transfer can take place while the user is waiting, or whether a queued transfer will be enforced by Mahara. Mahara should insert an 'intent' entry into a database table and send Moodle back the id, which Moodle will store in a queue table.

Config section

Moodle is then able to present the user with the config form, giving them the options of waiting (if allowed) as well as choosing the format to send the data in (this causes problems with the ordering of things - see Questions section), and any required metadata.

File ready ping

Once the user has confirmed the transfer, depending on whether the user has elected to wait or not, Moodle will either initate the package and send stages, or queue the item. Essentially these are the same. During both models, Moodle just sends a 'file ready' request to Mahara. In the interactive model, it also waits for the response from Mahara to say it has succeeded.

When Mahara sends the 'file ready' request, it also sends Mahara a location to retrieve the file from via a direct HTTP GET request. This is dependent on the file API in Moodle. As part of this request, Mahara will also send the original ID it sent back to Moodle in step 1, which Moodle is able to use to verify it should send the file.

Questions

  1. Ideally during the export config stage, Moodle should be able to let the user choose additional things, like what folder to put the outgoing file into. However, because the user doesn't select the export format until this same stage, this isn't possible. There are two options here, either just automatically put the files into an 'coming' folder in Mahara, or add an additional step to allow the user to select the target location. (Note that this holds regardless of format - blog posts that are being transferred natively (not for this development phase but potentially later) would benefit from the user being able to specify the target in Mahara.