Development talk:Portfolio API - Revision history

Dougiamas: /* Content & Formats / Meta data */

2008-07-01T07:40:02Z

Content & Formats / Meta data

← Older revision		Revision as of 07:40, 1 July 2008
Line 60:		Line 60:
	====Content & Formats / Meta data====		====Content & Formats / Meta data====

	2 examples to think on:		3 examples to think on:
	~~case1.~~ A user exports his thesis to his portfolio, you get the meta data from the install/course/grade/anything he adds and the file (any type)		# A user exports his thesis to his portfolio, you get the meta data from the install/course/grade/anything he adds and the file (any type)
	~~case2.~~ A user exports his forum post to his portfolio, you get the meta data from the install/course/grade/forum, you get his content of his post (txt/html?) and optionally have a file (any type)		# A user exports his forum post to his portfolio, you get the meta data from the install/course/grade/forum, you get his content of his post (txt/html?) and optionally have a file (any type)
	~~case3.~~ A user exports his case history from a database module which has 4 graphics files in it. you get the meta data from the install/course/grade/database instance, you get his content of entry(txt/html?) and the files		#A user exports his case history from a database module which has 4 graphics files in it. you get the meta data from the install/course/grade/database instance, you get his content of entry(txt/html?) and the files


Line 77:		Line 77:

	Obviously the design leaves room for those who may xpose into pdf the doc, ppt etc attachments, and so on (we automate this for some clients on a seperate box using open office)		Obviously the design leaves room for those who may xpose into pdf the doc, ppt etc attachments, and so on (we automate this for some clients on a seperate box using open office)



	====User Actions====		====User Actions====

Ghenrick at 00:43, 1 July 2008

2008-07-01T00:43:07Z

← Older revision		Revision as of 00:43, 1 July 2008
Line 77:		Line 77:

	Obviously the design leaves room for those who may xpose into pdf the doc, ppt etc attachments, and so on (we automate this for some clients on a seperate box using open office)		Obviously the design leaves room for those who may xpose into pdf the doc, ppt etc attachments, and so on (we automate this for some clients on a seperate box using open office)



			====User Actions====

			Pertaining mostly to portfolios, and perhaps student workspaces, some have asked about automating this completely. I think if you look at the stages
			- initiating xfer
			- meta data

			Could we not have a flag (per course? or instance or student?) perhaps to automate the transfer once something is complete (submitted graded etc..). It may also be useful to have an admin action to initiate this for all students "send all student data to portfolio"

			Could we not have a flag to not prompt students for more data as the people we have talked to mostly want this to be a "2 click" event, choose to export and confirm. I think it may be more difficult and create a barrier to use if students are prompted for meta data, so having this optional at admin level would be good.

			So a default simple install would automatically xfer all finalised content on enable modules to the students portfolio so they have it whether they forget to do so or not.

Ghenrick at 00:33, 1 July 2008

2008-07-01T00:33:02Z

← Older revision		Revision as of 00:33, 1 July 2008
Line 54:		Line 54:
	}		}
	}		}


			===Comments from Gavin Henrick===

			====Content & Formats / Meta data====

			2 examples to think on:
			case1. A user exports his thesis to his portfolio, you get the meta data from the install/course/grade/anything he adds and the file (any type)
			case2. A user exports his forum post to his portfolio, you get the meta data from the install/course/grade/forum, you get his content of his post (txt/html?) and optionally have a file (any type)
			case3. A user exports his case history from a database module which has 4 graphics files in it. you get the meta data from the install/course/grade/database instance, you get his content of entry(txt/html?) and the files


			IN the first case, you end up with meta data and a file of some type to export, how can a user define export format when its unlikely all will have servers capable of transforming to the chosen format.

			In the second case, you have data, content (txt) and a file of some format - again how can you transpose the content and the file and data into any given format?


			When we did the export we had the the end result as up to N files, the xml file(this is the meta data and could be csv,rtf, or html too), the html content file and the raw files which may be attached. Depending on where it is going, the meta data may end up as fields being pushed with the file, or so on. but i think holding it in a workable object (xml object or something else would be useful.


			Therefore I would propose that txt level output + files this be the lowest common denominator since everyone can generate it. xml,csv, or html for the meta data, and txt or html or rtf (since not all will be able to generate pdfs, and some content isnt that great in some pdf engines).

			Obviously the design leaves room for those who may xpose into pdf the doc, ppt etc attachments, and so on (we automate this for some clients on a seperate box using open office)

Nicolasconnault: /* Nico's reply */

2008-06-27T12:05:07Z

Nico's reply

← Older revision		Revision as of 12:05, 27 June 2008
Line 51:		Line 51:

	function query($query) {		function query($query) {
	~~$transport =~~ $this->~~get_transport();~~		$this->transport->query($query);
	$transport->query($query);
	}		}
	}		}

Nicolasconnault: /* Nico's reply */

2008-06-27T11:56:26Z

Nico's reply

← Older revision		Revision as of 11:56, 27 June 2008
Line 48:		Line 48:
	<?php		<?php
	class Portfolio {		class Portfolio {
			private $transport;

	function query($query) {		function query($query) {
	$transport = $this->get_transport();		$transport = $this->get_transport();

Nicolasconnault: /* Nico's reply */

2008-06-27T11:55:59Z

Nico's reply

← Older revision		Revision as of 11:55, 27 June 2008
Line 47:		Line 47:

	<?php		<?php
	~~...~~		class Portfolio {
	function ~~dothis~~(~~$portfolio,~~ $query) {		function query($query) {
	$transport = $~~portfolio~~->get_transport();		$transport = $this->get_transport();
	$transport->query($query);		$transport->query($query);
			}
	}		}

Nicolasconnault: /* Nico's reply */

2008-06-27T11:54:41Z

Nico's reply

@@ Line 35: / Line 35: @@
 I am fine with the idea of using libraries directly in portfolio/repository code, BUT with the following requirements:
 * Libraries must be object-oriented
-* The Transport object is a member variable of the Portfolio class
+* The Transport object must be a member variable of the Portfolio class
 There is no way to do proper unit testing without proper object orientation. If there is to be only one transport method per portfolio instance, then it should be a private member with public setters/getters. This will allow unit tests to mock the transport object, and test the portfolio code without having to worry about the transport code.

Nicolasconnault: Nico's comments

2008-06-27T11:51:39Z

Nico's comments

← Older revision		Revision as of 11:51, 27 June 2008
Line 30:		Line 30:

	Well theoretically moodle-moodle and moodle-mahara would both use mnet, although I guess you're right that it might be overly difficult. I was trying to avoid multiple wrappers around the same library. We started off as having formats as a plugin too and moved away from it in favour of libraries. I wonder if we gain anything in terms of test framework by adhering to one API for transport layers (think mock objects).. I'll ask Nico.		Well theoretically moodle-moodle and moodle-mahara would both use mnet, although I guess you're right that it might be overly difficult. I was trying to avoid multiple wrappers around the same library. We started off as having formats as a plugin too and moved away from it in favour of libraries. I wonder if we gain anything in terms of test framework by adhering to one API for transport layers (think mock objects).. I'll ask Nico.

			=====Nico's reply=====

			I am fine with the idea of using libraries directly in portfolio/repository code, BUT with the following requirements:
			* Libraries must be object-oriented
			* The Transport object is a member variable of the Portfolio class
			There is no way to do proper unit testing without proper object orientation. If there is to be only one transport method per portfolio instance, then it should be a private member with public setters/getters. This will allow unit tests to mock the transport object, and test the portfolio code without having to worry about the transport code.

Mjollnir: /* Penny's reply */

2008-06-24T09:34:10Z

Penny's reply

← Older revision		Revision as of 09:34, 24 June 2008
Line 19:		Line 19:
	[[User:Martin Dougiamas\|Martin Dougiamas]] 04:11, 24 June 2008 (CDT) Absolutely agree with Tim's picture, that is the same way the repositories API will work. Yes, the admin should choose to allow users to configure their own portfolios. This is basically saving user preferences for each plugin type, and could be part of the "save" process (use checkbox to save this portfolio for next time).		[[User:Martin Dougiamas\|Martin Dougiamas]] 04:11, 24 June 2008 (CDT) Absolutely agree with Tim's picture, that is the same way the repositories API will work. Yes, the admin should choose to allow users to configure their own portfolios. This is basically saving user preferences for each plugin type, and could be part of the "save" process (use checkbox to save this portfolio for next time).

	Yeah but still we have the model of admins creating instances of plugins and users can just configure them. They can't create their own instances.		Yeah but still we have the model of admins creating instances of plugins and users can just configure them. They can't create their own instances - [[User:Penny Leach\|Penny Leach]]

	====Do we really need transport APIs====		====Do we really need transport APIs====

Mjollnir: /* Penny's reply */

2008-06-24T09:33:51Z

Penny's reply

← Older revision		Revision as of 09:33, 24 June 2008
Line 18:		Line 18:

	[[User:Martin Dougiamas\|Martin Dougiamas]] 04:11, 24 June 2008 (CDT) Absolutely agree with Tim's picture, that is the same way the repositories API will work. Yes, the admin should choose to allow users to configure their own portfolios. This is basically saving user preferences for each plugin type, and could be part of the "save" process (use checkbox to save this portfolio for next time).		[[User:Martin Dougiamas\|Martin Dougiamas]] 04:11, 24 June 2008 (CDT) Absolutely agree with Tim's picture, that is the same way the repositories API will work. Yes, the admin should choose to allow users to configure their own portfolios. This is basically saving user preferences for each plugin type, and could be part of the "save" process (use checkbox to save this portfolio for next time).

			Yeah but still we have the model of admins creating instances of plugins and users can just configure them. They can't create their own instances.

	====Do we really need transport APIs====		====Do we really need transport APIs====