Module Structure: Difference between revisions

From IHRIS Wiki
Line 9: Line 9:
==metadata==
==metadata==
The DTD has for the <metadata> tag allows the following nodes:
The DTD has for the <metadata> tag allows the following nodes:
  <nowiki><!ELEMENT metadata (</nowiki>[[#displayName|displayName]],[[#className|className]]?,[[#category|category]]?,[[#description|description]]?,[[#creator|creator]]?,[[#email|email]]?,[[#link|link]]?,<br/> [[#version|version]],([[#enable|enable]]|[[#requirement|requirement]]|[[#conflict|conflict]]|[[#path|path]])*,[[#priority|priority]]?<nowiki>)></nowiki>
  <nowiki><!ELEMENT metadata (</nowiki>[[#displayName|displayName]],[[#className|className]]?,[[#category|category]]?,[[#description|description]]?,[[#creator|creator]]?,[[#email|email]]?,[[#link|link]]?,
  [[#version|version]],([[#enable|enable]]|[[#requirement|requirement]]|[[#conflict|conflict]]|[[#path|path]])*,[[#priority|priority]]?<nowiki>)></nowiki>
For the most part, the orders of these tags matter due to limitations in the structure of DTDs.  The exceptions is that the <enabled>, <requirement>, <conflict> and <path> tags can be listed in any order amongst themselves.
For the most part, the orders of these tags matter due to limitations in the structure of DTDs.  The exceptions is that the <enabled>, <requirement>, <conflict> and <path> tags can be listed in any order amongst themselves.
===displayName===
===displayName===

Revision as of 10:39, 11 March 2009

What is a Module

Module Configuration File

A module exists by defining its configuration files. There is one top-level node <I2CEConfiguration> under which there are two possible nodes:

The <I2CEConfiguration> tag has a required attribute name whose values should be a unique short name to describe this module such as I2CE, ihris-manage or my_custom_module. The DTD which describes the format of the configuration file is located in I2CE/lib/I2CE_Configuration.DTD.

metadata

The DTD has for the <metadata> tag allows the following nodes:

<!ELEMENT metadata (displayName,className?,category?,description?,creator?,email?,link?,
version,(enable|requirement|conflict|path)*,priority?)>

For the most part, the orders of these tags matter due to limitations in the structure of DTDs. The exceptions is that the <enabled>, <requirement>, <conflict> and <path> tags can be listed in any order amongst themselves.

displayName

This tag is requireed it is human readable name of this module which is displayed, for example, in the Configure Modules pa

Example: <displayName>Popup Box</displayName>

className

The tag is optional and it associates a class for the module. See #The Module Class for specific information about the module's class

Example: <className>I2CE_Module_JavascriptPopup</className>

category

This is an optional tag that is used to group similar modules together by category in the Configure Modules page.

Example: <category>Javascript Library</category>

description

This is an optional tag which gives a description of this module which is displayed in the Configure Modules page.

Example: <description>Provides a javascript popup box</description>

creator

This is an optional tag which shows the creator in the Configure Modules page.

Example: <creator>Freddy Mercury</creator>

link

This is an optional tag which gives a URL for the module in the 'Configure Modules page.

Example: <link>http://en.wikipedia.org/wiki/Freddie_Mercury</link>

version

This is a required tag which you can use to version your module.

Example: <version>1.0.0</version>

requirement

This is an optional tag, of which you can have as many as you want. Each tag needs to have the attribute name whose the value is the name of a module required by this module. This tag can have up to four possible sub-tags:

  • atLeast
  • atMost
  • lessThan
  • greaterThan

each of which need to have the attribute version with a value of a version of the module. As an example:

<requirement name='I2CE'>
 <atLeast version='3.1'>
 </lessThan version='3.2'>
</requirement>

says that our module requires that I2CE have version at least 3.1 and less than version 3.2.

In order for a module to be loaded, it must successfully meet all of its requirements.

conflict

enable

path

priority

Module Paths

Configuration (Magic) Data

See Technical Overview: Configuration (Magic) Data for more background information.

The Module Class

The Site Module