Developer Area/Mahara Architecture Introduction/Core Components
From Mahara Wiki
< Developer Area | Mahara Architecture IntroductionRevision as of 17:10, 16 May 2011 by Dirkca
The Mahara core provides some components instrumental to its structure. Parts of these components may be pluggable using the plugin system.
Almost all systems have users, and Mahara in particular provides next to no functionality that can be used without someone being logged in. The core allows users to register for the system, and manages their accounts. Many of the plugin types apply to aspects of users too. For example, auth controls how users authenticate to the system, and notification controls how users receive alerts about events within the system.
The basic unit of content in Mahara is called an artefact. All sorts of things are artefacts - blog posts & blogs, files, profile information and more. The artefact plugin type allows more to be added to the system, and as such is one of the most interesting plugin types. If you're thinking "I want to add X to the system" where X is something like wikis, calendars, polls etc, then you're probably going to be creating an artefact plugin to provide it.
Artefacts can belong to users, groups, institutions or the site itself. Some artefacts may make sense in the context of one of these but not the others - for example it might not make sense for users to have wikis (or maybe it might!), while it would make more sense for groups.
Mahara allows users to create ad-hoc groups. Groups are spaces within Mahara that various users can be a part of, to collaborate and discuss a certain topic. If you're a facebook user, think "Facebook group" - it's exactly the same concept. Various aspects of a group's behaviour can be configured using a grouptype plugin. Mahara ships with standard and course groups - the latter designed to group students, tutors and teachers in one formal place.
The Views framework provides one of Mahara's most powerful concepts. It allows users to quickly build pages combining both their own personal artefacts with other information from outside the system, and also gives users precise control over who can see those pages when. It provides a page builder which allows users to quickly pull together content for display using drag and drop.
The blocktype plugin type provides the ability to add different types of blocks that can be added to a View. Therefore, this is also a very interesting plugin type. Mahara ships with nearly 20 block types, and they're one of the smaller APIs to deal with, making creating new ones easy. Blocktypes can either use artefacts, or simply drag in content from outside the system. The ones that use artefacts are provided along with the artefact plugins themselves normally, making blocktypes the only plugin type that can be nested within another plugin.
Mahara ships with blocks to pull in video, RSS feeds and add blocks of text. In addition, each artefact plugin has blocktypes for its content - for example, the blog plugin has blocktypes for both inserting a blog and a blog post into a View.
One of Mahara's goals is to make it as easy as possible for users to interact across boundaries such as schools. As such, Mahara is designed so that an entire set of schools or institutions can use the one instance, and have all of their users work together. However, this can add challenges for support - it's desirable if one school has control over its users and can provide first level support for them. So Mahara supports the concept of institutions. They have their own administrators, themes and authentication mechanisms, and the administrators can perform basic actions such as resetting their users' passwords. This scales out all the way to a national level - the MyPortfolio service in New Zealand provides one Mahara for all schools and another for all universities across New Zealand.
Previous: Mahara Architecture Introduction
Next: Core Subsystems