Form Storage Mechanisms

A storage mechanism is defined by subclass I2CE_FormStorage_Mechanism which provides the methods to read, and possibly write, the data for any form with the given mechanism. If the data is stored in a database, it can sub-class I2CE_FormStorage_DB and provide read access to the data as a form by only defining one method, getRequiredFieldsQuery(). To make a storage mechanism writable, you only need to write a method which defines how to store a data field.

Once a storage mechanism is written, the data for that form can be queried via searches with [[Technical Overview: Limiting Forms |limits].

The currently (or soon-to-be) available storage mechanisms are:

• entry: A vertical database storage mechanism which keeps a history of when and by who individual fields (data elements) were changed. This is the default storage mechanism, and the storage mechanism that was used in version prior to 3.2.
• flat: A horizontal database storage mechanism, where a row of a table corresponds to an instance of a form. The columns, or any SQL function, of the table are used to define the fields.
• multi_flat: A horizontal database storage mechanism similar to the flat storage mechanism but combining several identically structured tables. It is primarily intended for data collation.
• magicdata: A locale aware storage mechanism primarily intended for centrally maintained lists of data.

Storage mechanisms are easy to write, and some other possibilities for storage mechanisms which could be added are for:

• Data stored in XML files.
• Data stored in a CSV file.

Much base functionality is provided in I2CE_FormStorage_Mechanism, although these methods may be overwritten to improve speed.