Making new Sloodle objects
From SLIS Second Life Wiki
Sloodle Versions: 0.3 (?)
This page is for anybody interested in creating a new Sloodle object to add to the toolset, and is specifically concerned with 'course centric' objects -- this means objects which are connected to a Moodle course or a particular part of a course, rather than connected to a user (as in User Centric Authorisation). The most important part of planning your new object is the data transactions. Please be sure to read and follow the Sloodle communications specification when deciding what your tool will do.
Contents |
[edit] Type Identifier
The first thing to do is decide on a 'type identifier' for your object. This should consist of two parts: a short name (lower-case letters only), followed by a dash, and a version number (start at version 1.0). For example, the WebIntercom tool, which connects SL/Moodle chat, started out as "chat-1.0" in Sloodle 0.3. If we make another version, it may be "chat-1.1".
Make sure your type identifier is unique and clear, and try not to make it too long! (No more than 12 characters, if possible).
[edit] Changes in Second Life
[edit] Main Script
You can use as many LSL scripts as you like in your Sloodle objects, but the main script that does the bulk of the work should be named "sloodle_mod_" followed by the type identifier. For example, the main WebIntercom script is called "sloodle_mod_chat-1.0", and the main MetaGloss script is called "sloodle_mod_glossary-1.0". This naming is very important, as it lets the other standard Sloodle scripts recognise what kind of object they need to configure. Please do not use the name "sloodle_mod_..." for any other scripts! :-)
It is normally important to make your object capable of receiving configuration information, e.g. from web or notecard configuration methods. The standard way to do this is make your "default" state almost completely idle. The only thing it will do is receive link messages on the SLOODLE_CHANNEL_OBJECT_DIALOG channel, which contain configuration commands. You can usually copy the default state from other objects, and be sure to copy the "sloodle_handle_command(..)" function too, and customize it to suit your needs. You will need to add/remove configuration settings, and make sure the function returns TRUE when it has got all the configuration data it needs, or false if it does not.
Your other states may behave as you like. If you want to completely reset your object and fetch a new configuration, send a "do:reset" link message on the SLOODLE_CHANNEL_OBJECT_DIALOG channel, and the configuration scripts will reset as well.
[edit] Localization Script
If your object outputs any text, then you will need to create a new LSL localization script. The naming convention is as follows: "sloodle_translation_NAME_LANG". The NAME part should probably be very similar to your object identifier, but it is sometimes different, especially if multiple similar objects share the same script. The LANG part should be a language code, such as "en" for English, or "fr" for French.
It is best to copy an existing script, rename it, and change the contents to suit your needs. You will also need to copy some code into your main script so that you can access the localization script. Read the Sloodle LSL Localization Script page for more details.
[edit] Standard Scripts
There are many standard Sloodle scripts which are re-used throughout many objects. It is often best to use these wherever possible, so that everything is consistent, and to save you programming time. Some of the common scripts are shown below:
- sloodle_translation_en - the code Sloodle localization script (normally used by all objects)
- sloodle_setup_web - performs web-configuration and sends messages to your other scripts via link message (compatible with notecard version)
- sloodle_setup_notecard - can read configuration from a sloodle_config notecard, and send messages to your other scripts via link message (compatible with web version)
- sloodle_active_object_ping - regularly notifies Moodle that the object is still active, to prevent it from being deauthorised due to timeout
- sloodle_email_login_details - receives emails and notifies users of their auto-registered account details via Instant Message (has bugs!)
- sloodle_layout_object - allows the object to save itself to a layout when request by the Sloodle Set
- sloodle_manual_reg_enrol - can conduct manual registration/enrolment procedures in response to link messages
- sloodle_multi_url_loader, sloodle_parallel_url_loader_x - allows parallel loading of multiple URLs to avoid script delays
[edit] Changes in Moodle
[edit] Module Class
If your object will access a Moodle module (such as a chatroom or a forum), then you will typically want to create a Sloodle module class for it. These are classes which effectively 'wrap' all the necessary functionality, such as database queries, with a fairly standard interface. This helps maintain consistency across different parts of Sloodle, and will hopefully make it easier for Sloodle to 'migrate' to other VLE platforms in the future. Additionally, it makes it possible for the Sloodle framework to automatically find and load your module.
Note: the module class should generally not output any information -- it should only be used to fetch and manipulate data.
You will find the module classes in "sloodle/lib/modules". Each module class should be derived from the base class defined in "module_base.php". It is often best to copy an existing module class file, to see how things are done, and customize the functionality to suit your needs. Don't forget to check the base module class to see if there are any standard functions already there, or which you could override.
If your module class filename starts with "module_" and ends with ".php" then Sloodle will find it automatically.
Above all else, it is very important to specify the type name in the "get_type()" function. This should usually match the type identifier you created above, and will allow the system to automatically find the module later on. See the Sloodle Module Class page for more information on this.
[edit] Object Folder
You will normally need to create an object folder for you object. You will find the object folders in "sloodle/mod", where you should create a new folder named according to your object identifier. There are typically at least 2 PHP files you will need to add here:
- "linker.php" -- a Linker Script which lets objects in SL communicate with Moodle (it helps to refer to the Sloodle PHP API for this)
- "object_config.php" -- outputs form elements to allow web-configuration (see Sloodle Web-Configuration Script) (name and content are very important... try to copy existing scripts)
[edit] Help!
I know this is an awful lot of information to get to grips with! The best thing to do is to start out creating just the Linker Script in Moodle and your main LSL script in Second Life, and don't worry about everything else. When your idea is more fully established, you can start to introduce the rest of the concepts. And if you get stuck, please ask on our development forums, or IM Pedro McMillan in-world (RL: Peter Bloomfield).
| This page is part of the Sloodle documentation | |||
|---|---|---|---|
| SloodleDocs Home | User Documentation | Administrator Documentation | Developer Documentation | Sloodle Wiki Home | |||
