Datamanager Schemas

From OpenPSA Wiki

Jump to: navigation, search

Through Datamanager 1 Schemas, version 1 of MidCOM Datamanager is configured. They serve as an abstraction layer between MidCOM and the Midgard MySQL Database.

Most MidCOM Components used to be based on these Schemas, and thus can be altered by user-defined Schemas. The default schema is located in config/schemadb_default.inc.

Starting with MidCOM 2.6., they are superseded by Datamanager2 Schemas, but midcom.helper.datamanager is still part of the distribution for compatibility reasons.

[edit] Creating custom Schemas

Schemas are regular PHP arrays and can be defined Sitegroup wide in the Snippetdir sitegroup-config:

  1. Create a Snippetdir named like the Component in question (e.g. de.linkm.newsticker)
  2. Create a Snippet named config with at least the following lines:
 "schemadb"       => "/sitegroup-config/componentname/schema",  
 "schemadbs"      => Array (  
  "/sitegroup-config/componentname/schema" => "Our schemadb",
 ),  
 "default_schema" => "default",

The actual Schemas are then defined in the Snippet schema

For a specific Topic, Schemas can be defined as well.

[edit] Schema Structure

Schemas from midcom.helper.datamanager are not compatible to midcom.helper.datamanager2.

 "identifier" => array (
    "name"        => "identifier",
    "description" => "Description",
     "fields"      => array (
       (...)
       ),
 )

Each Schema has to have a unique identifier and a (supposedly human-readable) description. In the fields array, the actual data structur is defined. An entry may look like this:

       "content" => array (
           "description" => "Text",
           "datatype"    => "text",
           "location"    => "content",
           "widget"      => "html"
       )

"content" is the unique identifier of the field, "description" the human-readable description which will be used during form rendering. "datatype" is one of the types the Datamanager can handle (see below), location determines where the field's content should be saved (in this case, in the content field in the table article_i of the Midgard MySQL Database). "widget" specifies the widget to be used for editing this field (see below).

Apart from these basic options, a number of more specialized options exist for specfic datatypes and widgets. There are also "top-level" options like "hidden" which can be set to true to hide the field in a Datamanager-produced form.

[edit] Location

tells which Midgard object property is used to store the contents of the field. These are the fields the object has in the Midgard MySQL Database. In addition to regular properties of an object, schema can extend the object with two additional locations:

parameter - store the content to a Parameter of the object
attachment - store the content to a file Attachment of the object
Personal tools