Resource types

It's quite a change indeed, but I think now is the time to do it. People don't like change, but it's best to do it in one go than constantly move the goalposts.

I don't see anything in there that isn't positive, but I didn't see something I was hoping would be in there.

One of the first things I teach users to do when introducing Moodle is uploading a resource, and immediately I have to appologise for something they (and I) find unintuitive. When you have just uploaded a file you must then specify that you want to choose it. While sometimes you need to choose or upload another file, most of the time you don't. Will Moodle 2.0 default to choosing the just uploaded file?

Wow! This is great. Definitely a step in the right direction. I love that local file and url resources will be (finally) separated and the individual resources will behave like other module plugins. Creating a common library for resources to make things easier for developing would be a good idea (it is mentioned now as possibility only). I feel that the repository should be its own plugin and any external repository should also be implemented as its own plugin. Modularity rules.

I think this is an excellent plan!

And the comment I have isn't even about the content of the plan, but about one bullet point in the first part... I'm almost sure this is not relevant but it was mentioned there so....

There is mention of media embedding in conjunction with TinyMCE.

By default, the way TinyMCE does this is that it embeds the actual <object> tag etc for that media item, which is probably not appropriate. If using TinyMCE in core Moodle, I would highly recommend removing its media embed feature and making one which relies on Moodle's own multimedia filters (ie by just adding a link), so that media files can be consistently presented (and the HTML code can be updated in future if need be, by changing the filter not every single instance) and so that there are no additional security issues.

Any integrated feature could then know about media plugin settings, so that for example it doesn't offer to embed SWF if you are a student and are not allowed to.

If there isn't time to do clever integration I would recommend just disabling the media embedding feature and relying on the 'link' one instead.

Anyhow just thought I'd pass on some of our experience of TinyMCE's media plague embedding. No comments on the substantive part of the document.

--sam

Looks like the right thing to do, and the right time to do it

For my own needs, I'd like to mention that Filtering of uploaded html files should work on XHTML as well as HTML - see MDL-9443.

Cheers,
Dave.

Yes, with everythng else that is changing this would seem to be a good time to tackle this. I've commented in Doc, but for discussion here...

The term "directory" is meaningless unless explained to most teachers etc. This would be a good tim to standardise the resource/course files terminology on "folder". See MDL-11841.

Hooray!

My thoughts:

• Hopefully this means one dropdown per topic sction instead of two
• I think each repository should appear as a sub-type on the drop-down (combined with the third point about JS). I know they are there in the file picker, but this isn't ideal IMHO because:
  • it adds an extra click each time to shoose the right one
    
  • it obscures the options that the filepicker offers in case people are new or in case a new plugin has been added that they haven't seen
• Have a progressively-enhanced JS layer that will use YUI dialogue control to allow links and files to be added without leaving the course page. This is the number one thing people want to do and it really doesn't need a whole new page - just title and file/link. The advanced options can be accessed via the editing icon(s) after it's added. The Project course format is a good start here. The JS can add extra options to the dropdown via DOM and open the file picker at the right plugin if necessary.
  

Looks good, here are my comments:

1. Migrate legacy files options on module edit screen

I understand why we need the flag, but must we really expose this to teachers? I think its a step backward to add options like this which are not relevant to teachers on the module edit screen.

2. Opening of New Windows

Completely agree with the reasons for removing the options for new windows.

However, in real usage of moodle, opening resources in a new window is still used extensively and I just don't think we can remove this functionality.

3. Post-upgrade processing

Regarding:

So the admin will have to sit there and go through all these resources and check them off to complete the upgrade. Until this process is finished none of these operations can be guaranteed to work so we might even think about disabling those operations:

• Backup
• Restore
• Import of a course

Instead of disabling those functions, could we not prompt the user to do the checking process at the time of backup? That way the burden isn't solely on the admin user to verify every single resource.

I have read the resource module file API migration document all the way through. It looks like a plan whose time has come. But it seems to me that there's one aspect that's missing. Maybe I spend too much time associating with Librarians but I saw no reference to handling metadata associated with Resources. The only space where information that could be termed metadata can be recorded is free-form in the 'introduction' field. This means that searching for resources over a collection of courses is basically about searching for file names. I'd like to think of faculty building up a central collection of useful resources common to a number of courses which they can label and tag and search easily. Metadata could surely be extracted from Word files, MP3 files, JPGs etc for starters. I'm not suggesting that every resource have Dublin Core metadata associated with it, but I do think that the usefulness of Moodle resources would be greatly enhanced by a simple metadata scheme which was searchable.