The name of the component being registered.

The package name of the component being registered. The package being referenced should contain all the business logic for the component being registered. This package is automatically loaded when Movable Type initializes itself and all of its components.

The name of the author of the component.

The version registry key stores the version number of the plugin or component being described. This value is used to display to a user, and is used to determine if newer versions of this plugin or component exist.

The value of version should be any valid positive floating point number and should not contain and letters or special characters.

Sample Values

• 1.0
• 2.05
• 0.03
• 0.45a invalid
• version 3 invalid
• 1.42.1 invalid

For those components that have custom data types that they define, it is highly recommended that they also define a `schema_version`. The `schema_version` is used by Movable Type to determine if changes are required to the structure of database when new components or plugins are installed. Each time Movable Type is loaded, the schema version of the database is compared to that of each component is compared to what is declared and stored within the system. If the declared schema version is greater then what is on record for that component, Movable Type begins the upgrade process to bring the schemas in sync.

The `schema_version` should be a simple integer, but can be a floating point number to indicate minute changes to the schema. Each time the schema for a component or plugin changes, the `schema_version` should be incremented.

Plugins and components may need to persist information into a database. Therefore, database tables need to be defined and generated within Movable Type's database. These tables are created and maintained for each registered "object type" in the registry. Movable Type's core even utilizes this framework to keep its own database up to date from release to release of the core platform.

The value of `object_types` is an array of keys, where the name of each key is the name of the data type being registered. The value then associated with each key is a package name where the complete definition of the object or class can be found. The package then contains specifics about the structure of the data in the database, in addition to all the business logic associated with the object.

See also: MT::Object man page. (TODO)

Example

    $registry = {
        version => MT->VERSION,
        schema_version => MT->schema_version,
        object_types => {
            'foo' => 'MT::Foo',
            'bar' => 'MT::Bar',
        },
    };

MT::Foo.pm

    package MT::Foo;
    use strict;
    __PACKAGE__->install_properties({
        column_defs => {
            'id' => 'integer not null auto_increment',
            'blog_id' => 'integer not null',
            'title' => 'string(255)',
            'text' => 'text',
        },
    });

Extending Existing Object Types

Movable Type allows object types to be extended. This allows plugins and components to insert and associate additional pieces of data with a pre-existing data type. Furthermore, these additional pieces of data become a seamless extension of the original data element, allowing that object to be sorted by and filtered by the new data element quickly and easily.

Extending an object is done by declaring the extension within the registry. For example, to add a new "ratings" field to the core entry object for the purposes of allowing users to attach a zero to fives star rating to entry, one would do the following:

    $registry = {
        object_types => {
            'entry' => {
                rating => integer,
            },
        },
    };

Whenever a component or plugin declares an object type that already exists, the that object_type declaration acts as an extension to the pre-existing object type. Remember, if a plugin or component every changes an object type it declares, or changes the nature of an extension to a pre-existing object type, the schema_version associated with that plugin or component should be incremented to signal to Movable Type that some database maintenance may be required.

Movable Type allows plugins and components to generate custom permissions that can be assigned to users. Permissions registered in this way will automatically appear within the user interface allowing administrators to immediate begin assigning that permission to users and roles.

The value associated with the `permissions` registry key is an array of permissions being defined. Each permission being registered in this way is itself a hash which defines the specific parameters governing the display and usage of that permission within the application.

Permission Properties

Permissions within the registry support the following properties:

(Not currently used for rendering in the UI, but will be in the future.)

• label - The name of the label as it should appear when displayed to the user.
• group - The permission group the permission should be displayed within (optional). Valid values are: 
  
  • sys_admin
  • blog_admin
  • auth_pub
  • blog_design
  • blog_upload,
  • blog_comment
• order - The sort key for your permission to customize where the permission is displayed relative to other permissions. (optional)
  

Note: as of MT 4.0, these values are hard coded in UI.

Permission Scope

Permissions can be defined to operated within two different scopes: a blog specific scope or a system wide scope. The scope of a permission is specified by prefixing the permission's unique id or name with either "blog" or "system" followed by a period (".").

For example, to register a custom permission, use the following syntax.

   $registry = {
       permissions => {
           'system.create_blog' => {
               label => trans("Create Blogs"),
               group => 'sys_admin',
               order => 100,
           },
       },
   };