Talk:Resource module file API migration - Revision history

Geoffr: /* Jmol Resource: Comment from Geoff */

2010-08-01T17:27:34Z

Jmol Resource: Comment from Geoff

← Older revision		Revision as of 17:27, 1 August 2010
Line 64:		Line 64:

	At their simplest, Jmol resources are Web pages so could be considered a specialised HTML Page Resource Module		At their simplest, Jmol resources are Web pages so could be considered a specialised HTML Page Resource Module
	At their most complex, Jmol resources are akin to IMS packages. Indeed, I have built Jmol into IMS packages using RELOAD. However, again it is much more cumbersome than using the Jmol Resource type configuration interface. That said, I do fully appreciate the portability of IMS packages between different systems.		At their most complex, Jmol resources are akin to IMS packages. Indeed, I have built Jmol into IMS packages using RELOAD. However, again, this is much more cumbersome than using the Jmol Resource type configuration interface. That said, I do fully appreciate the portability of IMS packages between different systems.

	Therefore I suggest the following development sequence (I'll be happy to have a go at this!)		Therefore I suggest the following development sequence (I'll be happy to have a go at this!)

Geoffr: /* Jmol Resource: Comment from Geoff */

2010-08-01T17:25:12Z

Jmol Resource: Comment from Geoff

← Older revision		Revision as of 17:25, 1 August 2010
Line 80:		Line 80:
	Secondary use cases: My additions in '''bold'''.		Secondary use cases: My additions in '''bold'''.

	simple media file presentation - images, flash, movies, mp3, etc. '''3D molecular coordinate files, .cml, .cif, .mol, .pdb, .xyz etc.'''		* simple media file presentation - images, flash, movies, mp3, etc. '''3D molecular coordinate files, .cml, .cif, .mol, .pdb, .xyz etc.'''
	serving of general html files created in external system - web pages, html exported from Word, content packages, etc. '''Web pages exported from built-in Jmol template'''		* serving of general html files created in external system - web pages, html exported from Word, content packages, etc. '''Web pages exported from built-in Jmol template'''
	presentation of non-standard media files - no full control over embedding, might require proprietary browser plug-ins (quicktime, windows media, real media, adobe shockwave) '''Java applets such as Jmol, FreeMind etc'''		* presentation of non-standard media files - no full control over embedding, might require proprietary browser plug-ins (quicktime, windows media, real media, adobe shockwave) '''Java applets such as Jmol, FreeMind etc'''

Geoffr: /* Jmol Resource: Comment from Geoff */

2010-08-01T17:24:33Z

Jmol Resource: Comment from Geoff

← Older revision		Revision as of 17:24, 1 August 2010
Line 80:		Line 80:
	Secondary use cases: My additions in '''bold'''.		Secondary use cases: My additions in '''bold'''.

	* simple media file presentation - images, flash, movies, mp3, etc. '''3D molecular coordinate files, .cml, .cif, .mol, .pdb, .xyz etc.'''		simple media file presentation - images, flash, movies, mp3, etc. '''3D molecular coordinate files, .cml, .cif, .mol, .pdb, .xyz etc.'''
	* serving of general html files created in external system - web pages, html exported from Word, content packages, etc. '''Web pages exported from built-in Jmol template'''		serving of general html files created in external system - web pages, html exported from Word, content packages, etc. '''Web pages exported from built-in Jmol template'''
	* presentation of non-standard media files - no full control over embedding, might require proprietary browser plug-ins (quicktime, windows media, real media, adobe shockwave) '''Java applets such as Jmol, FreeMind etc'''		presentation of non-standard media files - no full control over embedding, might require proprietary browser plug-ins (quicktime, windows media, real media, adobe shockwave) '''Java applets such as Jmol, FreeMind etc'''

Geoffr: /* Jmol Resource: Comment from Geoff */

2010-08-01T17:23:29Z

Jmol Resource: Comment from Geoff

← Older revision		Revision as of 17:23, 1 August 2010
Line 73:		Line 73:

	Hope I'm on the right lines with this.		Hope I'm on the right lines with this.

			----

			On further scrutiny, perhaps the Jmol Resource Type is best aligned with Scenario 2 of the general Resource Module mod/resource

			Secondary use cases: My additions in '''bold'''.

			* simple media file presentation - images, flash, movies, mp3, etc. '''3D molecular coordinate files, .cml, .cif, .mol, .pdb, .xyz etc.'''
			* serving of general html files created in external system - web pages, html exported from Word, content packages, etc. '''Web pages exported from built-in Jmol template'''
			* presentation of non-standard media files - no full control over embedding, might require proprietary browser plug-ins (quicktime, windows media, real media, adobe shockwave) '''Java applets such as Jmol, FreeMind etc'''

Geoffr: /* Jmol Resource: Comment from Geoff */

2010-08-01T15:35:27Z

Jmol Resource: Comment from Geoff

← Older revision		Revision as of 15:35, 1 August 2010
Line 69:		Line 69:

	1. Update Jmol filter for Moodle 2.0 (Should be straightforward)		1. Update Jmol filter for Moodle 2.0 (Should be straightforward)
	2. Convert the Jmol Resource Type to a Jmol Resource Module (The current Jmol Resource type was modelled on, amongst others, the HTML and Text Page Resource Types)		2. Convert the Jmol Resource Type to a Jmol Resource Module /mod/jmol. The current Jmol Resource type was modelled on, amongst others, the HTML and Text Page Resource Types, so the new version could be based on mod/page
	3. Consider 'converging' the Jmol Resource Module with the IMS Resource Module. i.e. making the the Jmol Resource Module a specialised form of IMS package. The aim would be to retain the resource-building interface, but allow import-export with other systems.		3. Consider 'converging' the Jmol Resource Module with the IMS Resource Module mod/imscp. i.e. making the the Jmol Resource Module a specialised form of IMS package. The aim would be to retain the (relatively) simple resource-building interface, but allow import-export with other systems.

			Hope I'm on the right lines with this.

Geoffr: /* Jmol Resource: Comment from Geoff */ new section

2010-08-01T15:28:53Z

Jmol Resource: Comment from Geoff: new section

← Older revision		Revision as of 15:28, 1 August 2010
Line 56:		Line 56:

	-- Ray Lawrence 15/6/09		-- Ray Lawrence 15/6/09

			== Jmol Resource: Comment from Geoff ==

			I think the Jmol Resource Type should also become a Resource Module (Not Filter, as suggested in the Development Docs)

			A separate Jmol filter already exists and does a different (simpler) job to the Resource Type. Latest versions of the Resource Type have a sophisticated configuration interface so that teachers can (relatively) easily build Jmol-based resources with different display options, controls and textual context. This would be (is) cumbersome to do through a Filter.

			At their simplest, Jmol resources are Web pages so could be considered a specialised HTML Page Resource Module
			At their most complex, Jmol resources are akin to IMS packages. Indeed, I have built Jmol into IMS packages using RELOAD. However, again it is much more cumbersome than using the Jmol Resource type configuration interface. That said, I do fully appreciate the portability of IMS packages between different systems.

			Therefore I suggest the following development sequence (I'll be happy to have a go at this!)

			1. Update Jmol filter for Moodle 2.0 (Should be straightforward)
			2. Convert the Jmol Resource Type to a Jmol Resource Module (The current Jmol Resource type was modelled on, amongst others, the HTML and Text Page Resource Types)
			3. Consider 'converging' the Jmol Resource Module with the IMS Resource Module. i.e. making the the Jmol Resource Module a specialised form of IMS package. The aim would be to retain the resource-building interface, but allow import-export with other systems.

Ray at 13:28, 15 June 2009

2009-06-15T13:28:25Z

← Older revision		Revision as of 13:28, 15 June 2009
Line 48:		Line 48:

	--[[User:Tim Hunt\|Tim Hunt]] 05:34, 9 June 2009 (UTC)		--[[User:Tim Hunt\|Tim Hunt]] 05:34, 9 June 2009 (UTC)

			== Some comments from Ray ==

			* References to "Directory". This is terminology that most teachers, trainers etc. are not familiar with. A good time to standardise on the term "folder". MDL-11841

			* Perhaps update spec table from "Links to external files in repositories (ie Hive)" to "Links to external files in repositories (e.g. Hive) ".

			-- Ray Lawrence 15/6/09

TimHunt: /* Some comments from Tim */ new section

2009-06-09T05:34:45Z

Some comments from Tim: new section

← Older revision		Revision as of 05:34, 9 June 2009
Line 32:		Line 32:

	--[[User:Eloy Lafuente (stronk7)\|Eloy Lafuente (stronk7)]] 09:49, 28 May 2009 (UTC)		--[[User:Eloy Lafuente (stronk7)\|Eloy Lafuente (stronk7)]] 09:49, 28 May 2009 (UTC)

			== Some comments from Tim ==

			Brilliant! Excellent detailed spec. Just a few comments:

			I added a few comments inline in the main page becuase it seemed easier. Please see main page history.

			For the resource_historic table - in the blocks code I used block_instance_old. old is shorter, is it worth being consistent?

			mod/page -> Show course blocks options. Martin said that that option could just be removed.

			is mod/link a better name than mod/url?

			mod/imspackage I have normally seen IMS Content Packaging abbreviated as IMS-CP. Since IMS may come out with other packaging schemes in the future, might it be better to call the module mod/imscp? Or would it be better to have one module to support all the packaging formats that we support? That is, should we go the other way and call it mod/contentpackage? (No, becuase SCORM will still be separate, and anyway, that name is too long.)

			--[[User:Tim Hunt\|Tim Hunt]] 05:34, 9 June 2009 (UTC)

Stronk7: /* TODO - explain exactly how pluginfile can derive ... */

2009-05-28T09:53:16Z

TODO - explain exactly how pluginfile can derive ...

← Older revision		Revision as of 09:53, 28 May 2009
Line 27:		Line 27:
	So for example, if we have one resource pointing to: ''"some/dir/with/index.html file"'', the ''"some/dir/with"'' directories will be created (if don't exist) in destination resource file area and then the ''"index.hml"'' file will be copied there (also, if don't exist, obviously).		So for example, if we have one resource pointing to: ''"some/dir/with/index.html file"'', the ''"some/dir/with"'' directories will be created (if don't exist) in destination resource file area and then the ''"index.hml"'' file will be copied there (also, if don't exist, obviously).

	Then, advancing in the example, if that html includes one link to say: ''"another/different/dir/style.css"'', then the '"another/different/dir"'' dir will be created (once again, if it doesn't exist) and then the ''"style.css"'' file with be copied there (do you guess when? :-P ).		Then, advancing in the example, if that html includes one link to say: ''"another/different/dir/style.css"'', then the ''"another/different/dir"'' dir will be created (once again, if it doesn't exist) and then the ''"style.css"'' file with be copied there (do you guess when? :-P ).

	That way, by retaining the "relative paths" ~~under~~ legacy course files when copying ~~stuff~~ to ~~proper~~ resource file areas, the only change will be that old resources being server by "file.php" will be now served by "pluginfile.php", (with different parameters related to course/context/filearea) but 100% equivalent ~~about~~ relative ~~paths~~.		That way, by retaining the "relative paths" present in legacy course files when copying them to 2.0 resource file areas, the only change will be that old resources being server by "file.php" will be now served by "pluginfile.php", (with different parameters related to course/context/filearea, not important) but 100% equivalent in all their relative links.

	--[[User:Eloy Lafuente (stronk7)\|Eloy Lafuente (stronk7)]] 09:49, 28 May 2009 (UTC)		--[[User:Eloy Lafuente (stronk7)\|Eloy Lafuente (stronk7)]] 09:49, 28 May 2009 (UTC)

Stronk7: /* Extracted from HQ chat, pending to confirm (Y/N) */

2009-05-28T09:49:52Z

Extracted from HQ chat, pending to confirm (Y/N)

← Older revision		Revision as of 09:49, 28 May 2009
Line 19:		Line 19:

	--[[User:Eloy Lafuente (stronk7)\|Eloy Lafuente (stronk7)]] 09:38, 28 May 2009 (UTC)		--[[User:Eloy Lafuente (stronk7)\|Eloy Lafuente (stronk7)]] 09:38, 28 May 2009 (UTC)

			==TODO - explain exactly how pluginfile can derive ...==
			Here it's a tentative explanation:

			The whole path (within legacy course files) will be fully retained when copying files to the resource files area.

			So for example, if we have one resource pointing to: ''"some/dir/with/index.html file"'', the ''"some/dir/with"'' directories will be created (if don't exist) in destination resource file area and then the ''"index.hml"'' file will be copied there (also, if don't exist, obviously).

			Then, advancing in the example, if that html includes one link to say: ''"another/different/dir/style.css"'', then the '"another/different/dir"'' dir will be created (once again, if it doesn't exist) and then the ''"style.css"'' file with be copied there (do you guess when? :-P ).

			That way, by retaining the "relative paths" under legacy course files when copying stuff to proper resource file areas, the only change will be that old resources being server by "file.php" will be now served by "pluginfile.php", (with different parameters related to course/context/filearea) but 100% equivalent about relative paths.

			--[[User:Eloy Lafuente (stronk7)\|Eloy Lafuente (stronk7)]] 09:49, 28 May 2009 (UTC)