2011-02-23T09:36:25Z

Jenny-gray: /* Structure */

This page is associated with discussion about allowing plug-ins to declare their own user settings screens.

* Forum thread http://moodle.org/mod/forum/discuss.php?d=168322
* Tracker issue MDL-26347

===Overview===

One strand of development for the Open University UK's next generation VLE focusses on features which allow the student to be able to personalise their experience with various different parts of the system. What it boils down to is them being able to switch bits on and off.

What I'd like is for a plug-in (module, block, course format, local plug-in...) to be able to define a user settings screen that relates to the plug-in and have that screen automatically added to the profile section of the settings block.

=== Discarded thoughts ===

Initially I thought this could be done through the custom user profile fields, where each plug-in would define a custom profile category (only editable through code) and each category would be displayed as a separate item in the profile settings navigation.

There was a lot of concern (see MDL-26347 comments) from Eloy and Petr about interdependence of functionality.

This new proposal builds on a suggestion from Tim in the forum thread to use user_preferences instead, since this does not have a UI for admins to interact with. Tim, Sam and I have worked together to rough this outline for further discussion...

===Database===

====Structure====

User preferences will be stored in the existing core user_preferences table, rather than in tables associated with the plug-in.

The user_preferences table will be extended to add a plug-in column, for improved data integrity (optional - the rest of this design could work without this change, either in the short term to allow an early inclusion in 2.0.x or for ever).

Current best practice is to include the plug-in name in the name of the user_preference, so this extension will simplify that. The table will be populated as follows

* Userid
** the id number for current $USER
** as currently defined
* plugin (or maybe component if that's newer moodle style)
** frankenstyle name
** allowed null for backward compatibility
* Name
** the setting being stored
** as currently defined
* value
** the user's choice
** as currently defined

====Get and Set functions====

The data continues to be accessed through the existing functions which are extended to cope with the optional plugin parameter.

===== get_user_preferences =====

An additional optional plugin parameter will be added. This will default to null if no parameter is passed, for backward compatibility.

If the plugin parameter is received then this, as well as the name and user parameters will be checked when accessing the data. Otherwise, just the name and user parameters, and a null plugin value will be checked.

===== set_user_preference =====

An additional optional plugin parameter will be added. This will default to null if no parameter is passed, for backward compatibility.

If the plugin parameter is received then this, as well as the name and user parameters will be inserted in the database. Otherwise, just the name and user parameters, and a null plugin value will be inserted.

===== set_user_preferences =====

This function takes an array of key/value pairs and saves all of them in the user_preferences table. This would be extended to optionally take an array of arrays of key/value pairs.

The first array would be indexed with the plugin name, so $array['plugin1'] contains all the key/value pairs for plugin1.

If an array of arrays is received, then each array's key/value pairs are inserted with the array's index inserted as the plugin value in the database row. If a simple array of key/value pairs is received, these are inserted with a null plugin value.

=== Settings block ===

The Settings block currently includes a Profile section, which expands to offer a link to edit profile. Users with the right permissions also see change password, roles and security key links.

This profile section will be extended to add a link to each of the user preferences screens defined by plugins. The link will be highlighted with CSS to indicate the currently open page.

The links can be added in navigationlib.php by adding a loop through all enabled plugins (of all types) looking for an appropriately named file (see below) defining a user preferences form. If found, a function call would check whether the link should be added (see below), and if returns true a link to the form will be included in the profile navigation.

==== Block display ====

The user/edit.php pages will need to display the Settings block. It's pagelayout will need to be set to something that displays user blocks to match the profile page. The user/edit page already has user pagetype, but a course context. This will cause difficulties with the block display and overlaps with issues Sam has reported in MDL-25189.

Some core themes (e.g. boxxie - it may be the only one, I haven't checked) add blocks on the user/edit.php page. These would need to be updated to remove that control, as being no longer necessary.

===Plug-in interface===

====Defining the form====

An optional file (userpreferences.php) will be added to each plugin which wants to define a user preferences interface.

Each userpreferences.php file will create a new form. This will not be a complete moodleform definition but a simpler definition similar to the way admin configuration settings.php files work. However, since the forms will be aimed at users rather than admins, the form fields will optionally need additional help text. (??? because of that would it actually be simpler to add a proper moodleform ???)

The exact definition of these files is the main part of this specification which requires further work - I thought it best to wait until the general principle could be agreed before spending too much time on that!

====Admin override====

It is possible that system administrators may want to hide the user preferences for simplicity. The userpreferences.php file (or the plug-in class definition??) will include a function (plugin_userprefs_link maybe??) which indicates whether or not the settings block profile link should be included. This will return true by default for all plugins.

However, plug-in developers making use of this feature should include an admin settings screen with an on/off checkbox, and then their choice would be returned rather than the default true.

As an extension of this, plug-in developers might give administrators the option to switch on and off individual settings within the plug-in's user preferences form. If all individual settings were disabled, the plugin_userprefs_link function should check this situation and return false regardless of the general admin on/off setting.

=== Further tidying up possible ===

A number of fields on the current user profile form could be moved and placed more appropriately with their plug-ins, or into a new form for general preferences. This would leave the main profile form solely responsible for personal data about the user.

Here is a list of current user profile fields which fall into this situation - most would problably move to a "general" tab as they affect multiple plugins. In particular, I'm not sure what to do with the messaging ones, as they shouldn't be disabled if system private messaging is disabled, but they don't belong just with forum.

* General
** Use HTML editor
** Ajax and JavaScript
** Screen reader
** Preferred language
* Messaging
** Email format
** Email display
** Email digest type
* Forum
** Forum autosubscribe
** Forum tracking

=== Generated settings form ===

The save and cancel buttons should intuitively take you back to the course home page. If they visit their profile from a course home or content page, the global $COURSE variable will be available and the id property can be used to define the redirect. Alternatively, the lastcourseaccess property of the global $USER variable stores the last visit on all their available courses, and so can be used to identify the last course they looked at for the definition of the redirect. If the lastcourseaccess property of the global $USER variable is empty, the user should be redirected to the latest course on which they were enrolled.

===Backup and restore===

User settings, because they are stored using the core user_preferences functionality are already catered for in backup and restore procedures, so no further extension will be required.

{{CategoryDeveloper}}

User preferences for plug-ins

2011-02-22T10:49:01Z

Jenny-gray:

This page is associated with discussion about allowing plug-ins to declare their own user settings screens.

* Forum thread http://moodle.org/mod/forum/discuss.php?d=168322
* Tracker issue MDL-26347

===Overview===

One strand of development for the Open University UK's next generation VLE focusses on features which allow the student to be able to personalise their experience with various different parts of the system. What it boils down to is them being able to switch bits on and off.

What I'd like is for a plug-in (module, block, course format, local plug-in...) to be able to define a user settings screen that relates to the plug-in and have that screen automatically added to the profile section of the settings block.

=== Discarded thoughts ===

Initially I thought this could be done through the custom user profile fields, where each plug-in would define a custom profile category (only editable through code) and each category would be displayed as a separate item in the profile settings navigation.

There was a lot of concern (see MDL-26347 comments) from Eloy and Petr about interdependence of functionality.

This new proposal builds on a suggestion from Tim in the forum thread to use user_preferences instead, since this does not have a UI for admins to interact with. Tim, Sam and I have worked together to rough this outline for further discussion...

===Database===

====Structure====

User preferences will be stored in the existing core user_preferences table, rather than in tables associated with the plug-in.

The user_preferences table will be extended to add a plug-in column, for improved data integrity (optional - the rest of this design could work without this change, either in the short term to allow an early inclusion in 2.0.x or for ever).

Current best practice is to include the plug-in name in the name of the user_preference, so this extension will simplify that. The table will be populated as follows

* Userid
** the id number for current $USER
** as currently defined
* plugin
** frankenstyle name
** allowed null for backward compatibility
* Name
** the setting being stored
** as currently defined
* value
** the user's choice
** as currently defined

====Get and Set functions====

The data continues to be accessed through the existing functions which are extended to cope with the optional plugin parameter.

===== get_user_preferences =====

An additional optional plugin parameter will be added. This will default to null if no parameter is passed, for backward compatibility.

If the plugin parameter is received then this, as well as the name and user parameters will be checked when accessing the data. Otherwise, just the name and user parameters, and a null plugin value will be checked.

===== set_user_preference =====

An additional optional plugin parameter will be added. This will default to null if no parameter is passed, for backward compatibility.

If the plugin parameter is received then this, as well as the name and user parameters will be inserted in the database. Otherwise, just the name and user parameters, and a null plugin value will be inserted.

===== set_user_preferences =====

This function takes an array of key/value pairs and saves all of them in the user_preferences table. This would be extended to optionally take an array of arrays of key/value pairs.

The first array would be indexed with the plugin name, so $array['plugin1'] contains all the key/value pairs for plugin1.

If an array of arrays is received, then each array's key/value pairs are inserted with the array's index inserted as the plugin value in the database row. If a simple array of key/value pairs is received, these are inserted with a null plugin value.

=== Settings block ===

The Settings block currently includes a Profile section, which expands to offer a link to edit profile. Users with the right permissions also see change password, roles and security key links.

This profile section will be extended to add a link to each of the user preferences screens defined by plugins. The link will be highlighted with CSS to indicate the currently open page.

The links can be added in navigationlib.php by adding a loop through all enabled plugins (of all types) looking for an appropriately named file (see below) defining a user preferences form. If found, a function call would check whether the link should be added (see below), and if returns true a link to the form will be included in the profile navigation.

==== Block display ====

The user/edit.php pages will need to display the Settings block. It's pagelayout will need to be set to something that displays user blocks to match the profile page. The user/edit page already has user pagetype, but a course context. This will cause difficulties with the block display and overlaps with issues Sam has reported in MDL-25189.

Some core themes (e.g. boxxie - it may be the only one, I haven't checked) add blocks on the user/edit.php page. These would need to be updated to remove that control, as being no longer necessary.

===Plug-in interface===

====Defining the form====

An optional file (userpreferences.php) will be added to each plugin which wants to define a user preferences interface.

Each userpreferences.php file will create a new form. This will not be a complete moodleform definition but a simpler definition similar to the way admin configuration settings.php files work. However, since the forms will be aimed at users rather than admins, the form fields will optionally need additional help text. (??? because of that would it actually be simpler to add a proper moodleform ???)

The exact definition of these files is the main part of this specification which requires further work - I thought it best to wait until the general principle could be agreed before spending too much time on that!

====Admin override====

It is possible that system administrators may want to hide the user preferences for simplicity. The userpreferences.php file (or the plug-in class definition??) will include a function (plugin_userprefs_link maybe??) which indicates whether or not the settings block profile link should be included. This will return true by default for all plugins.

However, plug-in developers making use of this feature should include an admin settings screen with an on/off checkbox, and then their choice would be returned rather than the default true.

As an extension of this, plug-in developers might give administrators the option to switch on and off individual settings within the plug-in's user preferences form. If all individual settings were disabled, the plugin_userprefs_link function should check this situation and return false regardless of the general admin on/off setting.

=== Further tidying up possible ===

A number of fields on the current user profile form could be moved and placed more appropriately with their plug-ins, or into a new form for general preferences. This would leave the main profile form solely responsible for personal data about the user.

Here is a list of current user profile fields which fall into this situation - most would problably move to a "general" tab as they affect multiple plugins. In particular, I'm not sure what to do with the messaging ones, as they shouldn't be disabled if system private messaging is disabled, but they don't belong just with forum.

* General
** Use HTML editor
** Ajax and JavaScript
** Screen reader
** Preferred language
* Messaging
** Email format
** Email display
** Email digest type
* Forum
** Forum autosubscribe
** Forum tracking

=== Generated settings form ===

The save and cancel buttons should intuitively take you back to the course home page. If they visit their profile from a course home or content page, the global $COURSE variable will be available and the id property can be used to define the redirect. Alternatively, the lastcourseaccess property of the global $USER variable stores the last visit on all their available courses, and so can be used to identify the last course they looked at for the definition of the redirect. If the lastcourseaccess property of the global $USER variable is empty, the user should be redirected to the latest course on which they were enrolled.

===Backup and restore===

User settings, because they are stored using the core user_preferences functionality are already catered for in backup and restore procedures, so no further extension will be required.

{{CategoryDeveloper}}

User preferences for plug-ins

2011-02-22T10:19:28Z

Jenny-gray:

User preferences for plug-ins

2011-02-22T10:10:18Z

Jenny-gray: New page: This page is associated with discussion about allowing plug-ins to declare their own user settings screens. * Forum thread http://moodle.org/mod/forum/discuss.php?d=168322 * Tracker issue...

Migrating to 2.0 checklist

2011-01-27T15:04:26Z

Jenny-gray: /* General */

These are things that OU developers have found so far to check/do in code we're migrating from Moodle 1.9 to 2.0. All information on the detail of this checklist can be found elsewhere in Moodle Docs, and particularly from the [[Migrating_contrib_code_to_2.0]]

Not all these things are essential for a rush job, but if you did all of them, then that'd be great. We should really mark each one with a priority of some sort!

Please add/edit this list!

==Database==

* Leave empty db/update.php file
* New $DB global objects with functions replace old db functions
* $DB parameters swapped to ?
* Add and strip slashes no longer required
* Remove use of ENUM and ENUMVALUES in install.xml file
* check use of sql_substr()
* Get_records() etc now always returning arrays, empty array in case of no records found.
* Db functions throw errors not return false on error
* DB functions offer strictness parameters e.g MUST_EXIST
* Update version.php numbers (esp required)

==Page display==

* New $OUTPUT header and footer functions
* Navigation links need to use $PAGE->navbar
* Make sure that you instantiate the moodle form before any call to $OUTPUT->header()
* Create a renderer
* Change the way image urls are displayed (not $CFG->pixpath any more)
* CSS changes
** Change styles.php to styles.css
** Change page id to new structure e.g. course-format-studyplan to page-course-view-studyplan

==Roles and Permissions:==

* array name to $capabilities in access.php
* Remove references to admin in access.php
* Rename legacy to archetypes in access.php
* Add manager archetype in access.php
* Ensure require_login as well as require_capability checks
* isguest() is depreicated, use !isloggedin() || isguestuser() instead

==Language strings==

* Rename language folder
* Change $a to {$a} in language files
* Change popup help files to _help lang strings and shorten
* Add $string[‘pluginname’] to lang file
* Add $string[‘pluginadministration’] to lang file

==Forms==

* Param_clean parameter type removed
* type required parameter for optional_and required_param
* Replace file form elements with new filepicker
* Replace htmleditor with editor form field type
* Change setHelpButton to addHelpButton. (You need to change the arguments, but the new ones are simpler.)

==General==

* Swap config_ files to edit and settings php files
* Fix whitespace & coding style
* rs_fetch_next_record($rs) is deprecated, in favour of the simple foreach($rs as $var). Calls to rs_close() must be replaced by $rs->close();
* Check functions deprecated list: https://docs.moodle.org/en/Development:Deprecated_functions_in_2.0
* Use print_error() or throw new moodle_exception not error()
* Replace all url strings e.g. in redirect() calls with moodle_url instances
* Move install/uninstall functions from lib to db/install.php, lib/uninstall.php
* Move images into pix folder (especially icon.gif), get path by calling $OUTPUT->pix_url('icon', 'local_whatever');
* Add 'supports' function in lib (modname_supports()) for modules (and blocks?).

Migrating to 2.0 checklist

2011-01-27T15:02:48Z

Jenny-gray:

These are things that OU developers have found so far to check/do in code we're migrating from Moodle 1.9 to 2.0. All information on the detail of this checklist can be found elsewhere in Moodle Docs, and particularly from the [[Migrating_contrib_code_to_2.0]]

Not all these things are essential for a rush job, but if you did all of them, then that'd be great. We should really mark each one with a priority of some sort!

Please add/edit this list!

==Database==

* Leave empty db/update.php file
* New $DB global objects with functions replace old db functions
* $DB parameters swapped to ?
* Add and strip slashes no longer required
* Remove use of ENUM and ENUMVALUES in install.xml file
* check use of sql_substr()
* Get_records() etc now always returning arrays, empty array in case of no records found.
* Db functions throw errors not return false on error
* DB functions offer strictness parameters e.g MUST_EXIST
* Update version.php numbers (esp required)

==Page display==

* New $OUTPUT header and footer functions
* Navigation links need to use $PAGE->navbar
* Make sure that you instantiate the moodle form before any call to $OUTPUT->header()
* Create a renderer
* Change the way image urls are displayed (not $CFG->pixpath any more)
* CSS changes
** Change styles.php to styles.css
** Change page id to new structure e.g. course-format-studyplan to page-course-view-studyplan

==Roles and Permissions:==

* array name to $capabilities in access.php
* Remove references to admin in access.php
* Rename legacy to archetypes in access.php
* Add manager archetype in access.php
* Ensure require_login as well as require_capability checks
* isguest() is depreicated, use !isloggedin() || isguestuser() instead

==Language strings==

* Rename language folder
* Change $a to {$a} in language files
* Change popup help files to _help lang strings and shorten
* Add $string[‘pluginname’] to lang file
* Add $string[‘pluginadministration’] to lang file

==Forms==

* Param_clean parameter type removed
* type required parameter for optional_and required_param
* Replace file form elements with new filepicker
* Replace htmleditor with editor form field type
* Change setHelpButton to addHelpButton. (You need to change the arguments, but the new ones are simpler.)

==General==

* Swap config_ files to edit and settings php files
* Fix whitespace & coding style
* rs_fetch_next_record($rs) is deprecated, in favour of the simple foreach($rs as $var). Calls to rs_close() must be replaced by $rs->close();
* Check functions deprecated list: https://docs.moodle.org/en/Development:Deprecated_functions_in_2.0
* Use print_error() or throw new moodle_exception not error()
* Replace all url strings e.g. in redirect() calls with moodle_url instances
* Move install/uninstall functions from lib to db/install.php, lib/uninstall.php
* Move images into pix folder (especially icon.gif), get path by calling $OUTPUT->pix_url('icon', 'local_whatever');
* Update the code template at the top of each file (see [[Code template guidelines]] for details
* Add 'supports' function in lib (modname_supports()) for modules (and blocks?).

Migrating to 2.0 checklist

2011-01-27T15:01:44Z

Jenny-gray: New page: h1. Plugin migration checklist These are things that OU developers have found so far to check/do in code we're migrating from Moodle 1.9 to 2.0. All information on the detail of this che...

h1. Plugin migration checklist

These are things that OU developers have found so far to check/do in code we're migrating from Moodle 1.9 to 2.0. All information on the detail of this checklist can be found elsewhere in Moodle Docs, and particularly from the [[]]

Not all these things are essential for a rush job, but if you did all of them, then that'd be great. We should really mark each one with a priority of some sort!

Please add/edit this list!

h2. Database

* Leave empty db/update.php file
* New $DB global objects with functions replace old db functions
* $DB parameters swapped to ?
* Add and strip slashes no longer required
* Remove use of ENUM and ENUMVALUES in install.xml file
* check use of sql_substr()
* Get_records() etc now always returning arrays, empty array in case of no records found.
* Db functions throw errors not return false on error
* DB functions offer strictness parameters e.g MUST_EXIST
* Update version.php numbers (esp required)

h2. Page display

* New $OUTPUT header and footer functions
* Navigation links need to use $PAGE->navbar
* Make sure that you instantiate the moodle form before any call to $OUTPUT->header()
* Create a renderer
* Change the way image urls are displayed (not $CFG->pixpath any more)
* CSS changes
** Change styles.php to styles.css
** Change page id to new structure e.g. course-format-studyplan to page-course-view-studyplan

h2. Roles and Permissions:

* array name to $capabilities in access.php
* Remove references to admin in access.php
* Rename legacy to archetypes in access.php
* Add manager archetype in access.php
* Ensure require_login as well as require_capability checks
* isguest() is depreicated, use !isloggedin() || isguestuser() instead

h2. Language strings

* Rename language folder
* Change $a to {$a} in language files
* Change popup help files to _help lang strings and shorten
* Add $string[‘pluginname’] to lang file
* Add $string[‘pluginadministration’] to lang file

h2. Forms

* Param_clean parameter type removed
* type required parameter for optional_and required_param
* Replace file form elements with new filepicker
* Replace htmleditor with editor form field type
* Change setHelpButton to addHelpButton. (You need to change the arguments, but the new ones are simpler.)

h2. General

* Swap config_ files to edit and settings php files
* Fix whitespace & coding style
* rs_fetch_next_record($rs) is deprecated, in favour of the simple foreach($rs as $var). Calls to rs_close() must be replaced by $rs->close();
* Check functions deprecated list: https://docs.moodle.org/en/Development:Deprecated_functions_in_2.0
* Use print_error() or throw new moodle_exception not error()
* Replace all url strings e.g. in redirect() calls with moodle_url instances
* Move install/uninstall functions from lib to db/install.php, lib/uninstall.php
* Move images into pix folder (especially icon.gif), get path by calling $OUTPUT->pix_url('icon', 'local_whatever');
* Update the code template at the top of each file (see [[Code template guidelines]] for details
* Add 'supports' function in lib (modname_supports()) for modules (and blocks?).

Migrating contrib code to 2.0

2011-01-27T15:00:01Z

Jenny-gray: /* See also */

{{stub}}

{{Moodle 2.0}}

The goal of this page is to provide a checklist of tasks to be considered to upgrade CONTRIB code to Moodle 2.0. Several significant changes have taken place including the File API, DB Layer, Navigation, Output renderer, etc. It would be good if we had a list that contributors could follow to help move them toward being able to migrate the code. Any help in building up this list is greatly appreciated.

''Please add useful links...''

== Installation ==

The 'requires' version in the plugin's version.php is checked to make sure it looks like Moodle 2.0. You should change this value to '2010112400' or later otherwise plugin installation will abort.

== Database ==
* [[DB_layer_2.0_migration_docs]]

== File system ==

== Forms API ==
* [[Using the File API in Moodle forms]]
* [[Using_the_file_API]]

== Themes ==
* [[Output_renderers]]
* [[Text formats 2.0|Text formats 2.0]] how user-entered content is handled.
* [[Migrating_your_code_to_the_2.0_rendering_API]] (n.b., some info outdated and may need updating)
* [[Themes_2.0]]

Some details of how to re-design image CSS for plugin code are in the main themes documentation: [[Themes_2.0_creating_your_first_theme#Using_images_within_CSS]]

Be aware that themes are now cached on the server and so emptying your browser cache will not refresh the CSS. This can only be done by going to the site administration->appearance->themes->theme selector page and clicking the 'invalidate theme caches' button.

== JavaScript ==
JavaScript is included in different ways now and will need to be migrated, see the PHPDoc comments in /lib/outputrequirements.lib and some (slightly outdated) advice here: [[JavaScript_guidelines]]

== Backup and Restore ==

* [[Backup_2.0_for_developers]]

== Miscellaneous ==
There are other coding changes such as:
* MDL-24063 which eliminates PARAM_CLEAN
* MDL-24058 about no longer using stripslashes or addslashes
* [[Deprecated_functions_in_2.0]]

Please feel free to add others that come to mind. CONTRIB maintainers should check their 2.0 versions for these and make sure that they are appropriately handled.

== See also ==

* [[Moodle_2.0_release_notes]]
* CONTRIB-1988
* http://cvs.moodle.org/moodle/blocks/upgrade.txt?view=markup
* http://cvs.moodle.org/moodle/mod/upgrade.txt?view=markup
* [[User:Frank_Ralf/Experience_of_converting_a_module_to_Moodle_2|Experience of converting a module to Moodle 2]] by Sam Marshall (perhaps that documentation should better live here? --[[User:Frank Ralf|Frank Ralf]] 16:36, 15 November 2010 (UTC))
* [[Local_customisation]]
* [[Migrating to 2.0 checklist]] list of things to look out for when upgrading a plug-in

2009-06-30T14:48:11Z

Jenny-gray: /* Harvesting courses regularly and a few other comments */

Regarding the course import for teachers to start from...
I can envisage a situation whereby the original course author finds new information/ideas and adds stuff to the master course after the teacher has downloaded it, which in the current model would not make it to the teacher as the download is a one off process which they will not repeat. I would prefer a model whereby a course can act as a master template which gets updated regularly so that new questions, resources, activities etc appear dynamically as hidden items within the teacher's downloaded course, ready to be reviewed and revealed if needed. This would be like maintaining your Moodle install using CVS - you get updates all the time as they are created.

It would also be good to be able to track how many people are using a particular course and to have some sort of meta-forum for discussing changes and developemts. Many teachers will end up using the successful/well designed courses, so it would make a lot of sense to have a way of pooling their shared experience and getting that feedback back to the original creator. -- [[User:Matt Gibson|Matt Gibson]] 18:51, 25 June 2009 (UTC)

== Harvesting courses regularly and a few other comments ==

I've put this in the forum, but I'll say it here as well. If a site has a lot of courses to share with a hub, perhaps because they are an OpenCourseWare provider, they might prefer to supply an RSS or OAI list rather than click "publish" on each individual course. OCW Consortium members are already encouraged to offer an RSS feed (with DC metadata) of all their courses that is picked up by a number of OCW search tools. I'm sure Moodle users in that community would love the same approach to mean they could be included in the hubs as well.

To aid course harvesting (but to make publishing easier anyway) I'd like to see the DC metadata editing screen become part of the standard course settings screen, and the data pulled from here as part of the publish to hub functionality (and into any RSS or OAI service).

Using LOM as well as (or instead of) DC would allow more flexible searching at the hub with relatively little extra cost of data inputting.

Finally, there is a great deal of discussion in the OCW community about asset-level re-use. Anecdotal evidence from teachers suggests that the course-level is not fine-grained enough and they'd prefer to pick a single resource/image/activity. See http://opencontent.org/blog/archives/900 and related comments for example. So I'd like to see DC metadata added to resources and modules too, and the searching and import/export/enrol facility in the hub system work at this level also.
-- [[User:Jenny Gray|Jenny Gray]] 14:48, 30 June 2009 (GMT)

Talk:Community hub

2009-06-30T14:47:25Z

Jenny-gray: /* Harvesting courses regularly and a few other comments */ new section

User talk:Frank Ralf

2008-12-15T11:13:02Z

Jenny-gray: /* OpenLearn XML */

==FAQ pages==

Hi Frank, thanks for creating [[XML FAQ]]. I hope you don't mind that I made a start on [[Import and export FAQ]]. Your help in adding more content to these pages would be much appreciated. --[[User:Helen Foster|Helen Foster]] 04:21, 4 December 2008 (CST)

== OpenLearn XML ==

Some useful resources on OpenLearn XML format:
* http://www.derby.ac.uk/pocket/cdk/xml
* http://labspace.open.ac.uk/mod/resource/view.php?id=343529
* http://labspace.open.ac.uk/mod/resource/view.php?id=343530

--[[User:Frank Ralf|Frank Ralf]] 08:42, 11 December 2008 (CST)

Latest OpenLearn Schema is version 1.2 available from http://openlearn.open.ac.uk/local/sa/schemas/OUGeneric_v1.2.xsd This is the Open University (UK)'s xml schema used for all content production. We then render this into HTML and use core Moodle functions to create content in the moodle database to display that HTML.

== Moodle XML Schema roadmap ==

Here are some unsorted first thoughts about the best way of creating a Moodle XML Schema:

* Creating a XML Schema based on the Moodle XML documentation
* Modular schema, one for each question type: better extensibility
* Comparison with OpenLearn XML Schema
--[[User:Frank Ralf|Frank Ralf]] 08:19, 12 December 2008 (CST)

User talk:Frank Ralf

2008-12-15T11:10:31Z

Jenny-gray: /* OpenLearn XML */

==FAQ pages==

Hi Frank, thanks for creating [[XML FAQ]]. I hope you don't mind that I made a start on [[Import and export FAQ]]. Your help in adding more content to these pages would be much appreciated. --[[User:Helen Foster|Helen Foster]] 04:21, 4 December 2008 (CST)

== OpenLearn XML ==

Some useful resources on OpenLearn XML format:
* http://www.derby.ac.uk/pocket/cdk/xml
* http://labspace.open.ac.uk/mod/resource/view.php?id=343529
* http://labspace.open.ac.uk/mod/resource/view.php?id=343530

--[[User:Frank Ralf|Frank Ralf]] 08:42, 11 December 2008 (CST)

Latest OpenLearn Schema is version 1.2 available from http://openlearn.open.ac.uk/local/sa/schemas/OUGeneric_v1.2.xsd

== Moodle XML Schema roadmap ==

Here are some unsorted first thoughts about the best way of creating a Moodle XML Schema:

* Creating a XML Schema based on the Moodle XML documentation
* Modular schema, one for each question type: better extensibility
* Comparison with OpenLearn XML Schema
--[[User:Frank Ralf|Frank Ralf]] 08:19, 12 December 2008 (CST)