Talk:Portfolio API

Comments on specification

Please leave your name and indent according to reply structure.

Comments from Tim Hunt

Do we have to restrict it so that only admins can configure repositories

Here is an example user story:

A course somewhere out there about good online teaching requires students to participate in an online community, say, Moodle.org, and record evidence of their activity to their Portfolio. Moodle.org is a nice open place, so wants to help this sort of thing. Therefore, Martin configures it so that any user can go to their user profile, and configure any portfolio plugin for their own use, so students on this course can easily export from moodle.org to their own Portfolio.

Similarly, this may be a way to deal with Facebook authentication issues. Each student configures the facebook plugin for themselves, including some sort of secret key.

Penny's reply

Hmm. I agree with your user story but I'm not sure of the implications of it. At any rate, the portfolio plugin system must support multiple instances of a plugin being configured (iirc, this will be the first instance of this in moodle?) but then in terms of permissions I'm not sure how it would work - it's almost a new context level - so that any user could configure a plugin instance and then grant access. I think it should definitely be able to be turned off though (by an admin)

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 - Penny Leach

Do we really need transport APIs

I am not if transport layers really need to be pluggable APIs as such. Surely almost all Portfolio plugins will use a single transport method.

Of course, each transport method will have a library of code, for example a SOAP library, or the mnet libraries, and the Portfolio plugins will use these, but I don't see any need for all the transport mechanisms to implement some common interface. Different transport mechanisms work very differently, and tend to have different interfaces in their standard libraries. Trying to put a common wrapper round all of them seems difficult and unnecessary to me.

Penny's reply

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 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.

Here is some pseudo-code:

 <?php
 $portfolio = new PortFolio();
 $transport = new Transport_Mnet();
 $portfolio->set_transport($transport);
 ?>

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