Up to Unit 7 of the introduction to Moodle programming course, this one is titled “Replicating a moodle block”. So the programming begins.

Creating a simple block

Looks like we’ll be doing most of the standard stuff, adding tables, using forms CRUD…Staring with this tutorial from the Moodle site. THe process

  • Create a single file in a single directory
    ~/blocks/lowercase name of block is the directory and block_lowercase name of block.php is the file.
  • File format:
    • first line is block class definition – fixed naming convention
    • class must have an init() method – initially to set to class member variables title and version
    • get_content – required before it will display something on screen

Bugger, laptop migration didn’t work 100% with permissions – XAMPP is playing silly buggers, and now so is Moodle. Ahh, CVS wasn’t brought across in the migration either. Bugger, Apple developer CDs – long time to download to get CVS…..

Okay, back to it.

Misc other stuff

  • instance_allow_config method returns true to allow instance configuration
  • config_instance.html – used to specify HTML/PHP/Moodle functions to implement form to allow configuration
  • can’t use config variables in init section of blocks
  • specialization method is automatically called after init – used to apply config i.e. to specialize the block
  • instance_allow_multiple method allows multiple instances of the block for a single course – if it returns true
  • has_config – indicates global configuration exists if it returns true – i.e. allows application of config to all instances in all courses.
  • config_global.html – specify HTML form for global configuration

Skip to Unit 9 – requirements documents

While that’s downloading, time to move on. Will need to think about a requirements document some time soon to keep the organisational hierarchy happy and it will probably not require any code. Onto unit 9 – requirements documents.

Ahh, believes a requirements document will reduce feature creep – philosophically I disagree with this. It allows the developer to ignore the user’s growing knowledge of what they’d like to do with the application. It closes off possibilities – or at least that is how it is used.

It’s all fairly standard requirements document guff, little specific to Moodle. Most of it is just really limited in being of any use in a real situation.

This section of the Moodle developer docs seems to be a bit more useful and talks about creating a specification in Moodle docs. This one is used as the example.

. Some other alternatives include: specification of Workshop 2.0, blog improvements.

This will have to come later.

What’s next?

Looks like the reinstall of Moodle is going to take a while. Running out of time today. Not all that productive – but that’s what you get for changing laptops.

At this stage, it looks like it will be time to move onto the planning and documentation. Which also implies doing a presentation at CQU to generate more requirements. The interesting part of this will be working out which of the types of plugins (or how many of them) BAM will required.

For example, for students, registering their blog and checking marking progress could be thought of as activities. Configuring BAM for a course could, as it stands, be for an assignment. However, I’m not sure I want to limit use of BAM only for assessment. Why not use it as a basis for a course blog – aggregate – oops, is this feature creep?