As a part of the EU4ALL project, I have been trying to figure out how to add a new resource type. The idea is to add a resource known as an 'adaptable resource', whereby different media types are presented to the user depending on their accessibility preferences. The issue of how and where to assign or change these preferences is currently a question that has to be resolved. This post is intended as a bunch of 'notes to self' about what I have found during the last couple of days exploring and poking around the Moodle code base.
To explore the code, I've been using a couple of tools: SQLYog, which was recommended to me by an illustrious IET developer (to allow me to explore an instance of a Moodle MySQL database I have running on my home machine), and NuSphere, a PHP IDE. I did try the Zend IDE a year or so back, but abandoned it since I became rather confused!
So, how is it possible to add a new resource to Moodle? Initially, I decided to look at an existing resource, beginning with the simplest one that I could find: a simple text resource. By browsing the code base I seemed to find the rough area where the 'resource code' lives. I also browsed around the developer documentation page an unearthed a resource class template. Great!
In development, one question instantiates a tree of others. The most fundamental question is: how does this code work? I need to answer this big one to make a change. This is too big, so I split it into two other questions: (1) how can you modity a form that allows you to enter the parameters that describe an adaptable resource (currently it is to be a simple numerical value, from what I understand), and (2) how can I take the values held within a form and update them to the MySQL database? This requires an understanding of further magic code. As a note to myself, let's have a look at each of these in turn.
Looking at the text resource code, there seemed to be a bit of object-oriented polymorphism going on. The name of the directory where the resource code is important too! There is a magic function called display which appears to make some further magic calls to create some data entry fields - but these calls are quite a long way away from the pure HTML that is presented in the browser window.
This is another question: how does the magic functions in display() get turned into HTML? The answer apparently lies with the application of a forms library called PERL. If I figure out how to add functions in a way that would work for this library, I can ask the user for whatever I want.
The form uses some object-oriented principles. Individual controls are added to 'the form', and then a function is executed that 'prints out' or renders each of the controls, without you having to go near to producing your own HTML.
Another interesting observation, is that the display function I have uncovered only relates to a small part of a bigger form. This is due to subclassing and polymorphism that is being used, but this is a distraction... now I have a little understanding of what is happening (thanks to the NuSphere debugger!), I'll park this question for the time being. There are other mysterious areas to explore!
When a Moodle user edits a course resource, there are a couple of buttons that appear at the bottom of the screen. These are 'save and return', 'save and display' and 'cancel'. Looking at these buttons from a HCI perspective I think, 'buttons doing two different things?? surely this is a bad idea!'. But I digress.
My question is, 'what happens when the tutor (or administrator) clicks on either of the save buttons - where does the data go? Or more precisely, how does the data get saved?
Moodle seems to have a thin database layer: a set of functions that allows you to send SQL statements and receive data in response. Since the contents of the resource form is held in what can only be described as a 'big variable' (PHP has a funny approach to object-oriented programming if you've used other languages), the Moodle developers have figured out a way to transfer the contents of a form to the database, by matching on-screen fields to database fields.
This seems to work well: but on the downside is the database update code that Moodle code generates appear to be rather big, and an implicit dependency is created between the form and the database structure. Other systems that I've looked at make use of stored procedures, which has the potential to boost performance and security on one hand, but on the other restrict the database platforms that an application can be used with.
Now I know (roughly) how to add extra bits to a new resource type, the next thing I have to do is figure out how to write the functions that I need. After I've done that I'll have to hook up my edits to the database, and figure out how to best display the data that I've produced. I already have some idea about how to do this since I have created a paper prototype.
But before going down that road, I think I'll continue my survey of the Moodle codebase by exploring what sections can potentially relate to adding and manipulation of user parameters and settings. I think I'll start by looking at the user profile developer pages.
Looking towards the longer term, I will also have to connect Moodle to a number of different web services. Wish me luck!