This sounds like a good idea in that it makes the code shorter (and hopefully faster to write!) without losing readability.
Perhaps $DB->must_get_record() works better as a name (or family of names if this is going to be replicated consistently for other $DB->get functions).
I do see Eloy's point about the purity of the class, but I think if we see these as "add-ons" to DML then it's OK with me. The point of an API is to be as useful as possible after all.
Martin Dougiamas
Interventi di Martin Dougiamas
Thanks Jonathan, good point that we should be storing outcomes and allowing searches on them! I've added that to the spec.
About sharing activity/resources you can already do that with the current spec and the same course format.
ie when backing up the course you simply select which activities you want to include. The "course" metadata then simply applies to the one or more activities in the "courselet" package. You can choose a subset of activities during restore as well.
Note that we store a "course map" numbering how many of each different type of activity the package contains, so that it's easy to see a package that just contains one glossary, for example.
I do think the backup/restore interfaces could use a little bit of polishing/improvement when used for this but it really does work now and it keeps things very simple (one format for all!)
See this discussion from 2004 on courselets. We are finally getting there!
ie when backing up the course you simply select which activities you want to include. The "course" metadata then simply applies to the one or more activities in the "courselet" package. You can choose a subset of activities during restore as well.
Note that we store a "course map" numbering how many of each different type of activity the package contains, so that it's easy to see a package that just contains one glossary, for example.
I do think the backup/restore interfaces could use a little bit of polishing/improvement when used for this but it really does work now and it keeps things very simple (one format for all!)
See this discussion from 2004 on courselets. We are finally getting there!
I intentionally avoided having the hubs "pull" from registered sites, preferring to let sites "push" info in as necessary (since it is quite resource intensive to create backups). My feeling is that most admins would prefer to have the control.
However, it shouldn't be too hard to knock together something to push things out to the hub if that's what the admin wants. Not sure about how the feed would work ... do you have any time to flesh out some thoughts on the whole process here?
However, it shouldn't be too hard to knock together something to push things out to the hub if that's what the admin wants. Not sure about how the feed would work ... do you have any time to flesh out some thoughts on the whole process here?
Yes, we were thinking that:
- you could enter in the metadata on the course settings form (in a tab)
- enter/update the stored/sent info at the point of publishing as well
- if no data had been set yet, then fields are pre-filled as much as possible from existing information
About the format, I don't have strong feelings. I actually took Eloy's advice about using DC, but am happy to switch to LOM if that's what most people would prefer.
I do feel strongly that we should standardise on one format for all internal storage, search forms and data entry.