Common Functionality - Database Options in Common Functionality 7.2

A library to assist in quickly creating an options table and functions.

Justification: Options are normally stored in the php module itself inside of some static function. Using a function to get a list of possible options is the simple and efficient way to do this under normal circumstances.

Instead of using a function to define the options provided by some module, this project uses the database. While this has a cost in performance due to using database calls, this provides more flexibility and scalability. For example, as of drupal 7, external databases are supported. Lets say that for whatever reason these options and tables using them are stored in an external database that a third-party application may access. Lets say that the third party application is written in Java. That java application will have no idea what options are available if they are stored in the php file. When the options are defined and stored in the database, all it needs to know is where to look for the possible options.

The strategy defined here is to define a unique id, a machine name, a human name, and a description for each option. This allows for compatibility with the drupal standard practice of using machine names for options while still providing a database efficient practice of using numeric ids when associating with some option. The most notable downside to this strategy is importing and exporting of the database calls. The database unique ids for each option are unique only to a single drupal installation. To import and export, the machine name must instead be used.

Parent topics

File

modules/cf_db_options/cf_db_options.module, line 8

Common Functionality - Database Options module.

Functions