Talk:Using the File API in Moodle forms

I honestly don't know what this doc is saying in regards of how to use the file api. Should give more details on how to handle the mform file data.

The two code examples in the middle of the document seem a bit random. Some explanation of what's going on in them would be really useful --Howard Miller 08:32, 7 December 2010 (UTC)

Choosing whether an external resource should be copied into Moodle or referenced by Moodle

With most Add Resource and Add Activity options, the file picker automatically copies the file from the external repository into Moodle's draft area by calling getFile(UUID) on the repository plug-in.

This can be problematic for customers that require (for copyright or security reasons) that all content reside within the repository. It is particularly tricky when the remote content is changing through a version control or workflow process as the Moodle copy will be out of sync with the repository original. These are common requirements for users of HarvestRoad Hive(tm).

Long term Moodle-Hive customers were familiar with this model from a custom integration HarvestRoad built with Moodle 1.9. When the content is updated in Hive, Moodle users see the updated content. Furthermore, no sync process or cron job is required.

The file picker behaves differently when launched with the "Add Resource > URL" option. The file picker calls getUrl(UUID) on the repository plug-in instead, which is pretty much what Hive customers would like to do.

Proposed solutions:

1) Quick: Rather than always copying the file into Moodle, offer a choice in the file picker of copying the resource, or creating an URL to the external location of the resource. You could have two radio buttons under "Choose licence" on the file picker screen perhaps. This solution might not work if the repository does not support direct URL access or requires authentication.

2) More elaborate: offer a choice in the file picker of copying the resource, or creating a reference to the external resource. The reference in this case would be the UUID returned by the file picker. If the user chooses to create a reference then the call to getFile(UUID) would be omitted when using the file picker, and is instead invoked every time the item is viewed. If the item retrieval requires authentication then the repository plugin will perform the authentication.

The Hive team have partially implemented solution number 2, however the resource has to be added as a URL which is not ideal. In our solution our getUrl(UUID) creates an URL which actually points back to our Moodle repository plug-in which in turn streams the file from Hive. That is how we solved the authentication issue.

eg: http://hive43demo.harvestroad.com.au/moodle2/repository/hive/view.php/5/50/812/peugeot.jpg

In the above URL we have

* http://hive43demo.harvestroad.com.au/moodle2 => moodle server
* /repository/hive => Hive repository plug-in
* /view.php => Hive repository plug-in stream.er It streams the content from Hive and then re-streams it back to the client. Authentication is performed implicitly if required.
* /5/50/812 => Hive proprietary UUID
* /peugeot.jpg => just a filename

Bear in mind that Moodle itself should be agnostic about the UUID. The UUID is given by the getListing() method in the repository plug-in and it just needs to be passed back to getURL(UUID) or getFile(UUID)

To summarise, it would be useful if Moodle could store the UUID of the picked resource rather than downloading the resouce per se. The UUID can then be used at request time in order to stream the resource via getFile or to create an Url to it via getUrl.