Boolean field

Thank you fortytwo very much. This is very useful and needed long ago. I think many people just using integer or text types istead of boolean taking as allowed values text true/false or digits 0/1. But boolean field is much esier to create, validate and using less resource of database.

Can you only improve this module to taking empty value as well as true and false? This is needed when field isn't requiered, becouse if checkbox is empty it mean false, if it is select it mean true and there no posible to set empty value, so user like it or not must choose true or false. Maybe we should use widget other than checkbox.

I tried to provide some code to improve this module but I still don't know Drupal enough. Maybe Select/Textbox/Radio Field issue can help you fortytwo becouse it have much in common, but you must carefully read comments, especially when JonBob express differentiate between fields and widgets.

OK fortytwo, I will try produce some code. If someone want help my please wait till I share it here.

Please carefully review this code becouse I'm newbie. I think there are some bugs and not the best solutions because of existing modules or performacne. I'd like to get this issue commited, so please help me if you can.

My principles:

1. I renamed module to "boolean" becouse as far I understand "bool" is abbreviation of "boolean", but "boolean" is short name so we needn't use "bool". Besides PHP and PostgreSQL use "boolean" (MySQL have "bool" and "boolean" as alias of "tinyint(1)").
2. To store boolean field in database I used varchar(1). And we have 'Y' for Yes (True), 'N' for No (False) and '' for empty field. Originally I tried to use tinyint(1), but in this case we will need NULL value in database and as I figured out in other module there are no NULL values, only empty string or 0. Please see my NULL values issue.
3. Allowed values are translated words 'Yes' and 'No' based on Improved handling for optionwidgets. I put in this module boolean_allowed_values($field) function. Moreover, if field is not requiered, '' is allowed too. We have issue, that Improved handling for optionwidgets don't solved problem of using text field instead of select list or check boxes/radio buttons. When we have N|No and Y|Yes, in text field should be possible to put Yes/No instead of Y/N or both.

ATTENTION: I developed this code when Improved handling for optionwidgets is commited in its current stage.

Revision of principle 2:
If NULL values issue will be accepted (probably will be) and becouse of things maked a move (see: Content module will not store NULL values and Default values for fields) I think for better performance of database we should use tinyint(1) (boolean, bool) instead of varchar(1). If above-mentioned issue will get through, we will use NULL/0/1 values of this field. This is very important to creating this module, that database storage way bring real benefit in comparison with text or integer modules. In addition we want easier creating and validating Yes/No fields, and maybe using this module instead of others bring more benefit in Views etc.

Attachment with some changes.

For boolean fields PostgreSQL use "boolean", MySQL use "tinyint(1)" witch have aliases "bool" and "boolean". Becouse in content_admin.inc we have:

  switch ($GLOBALS['db_type']) {
    case 'pgsql':
      $mappings = array(
        'int' => 'integer',
        'mediumint' => 'integer',
        'bigint' => 'integer',
        'tinyint' => 'smallint',
        'float' => 'float',
        'varchar' => 'varchar',
        'text' => 'text', 'mediumtext' => 'text', 'longtext' => 'text');
      if (isset($mappings[$type])) {
        $type = $mappings[$type];
      }
      else {
        watchdog('database', t('No PostgreSQL mapping found for %type data type.',
array('%type' => $type)), WATCHDOG_WARNING);
      }
      if ($type != 'varchar') {
        unset($attributes['length']);
      }
      break;

    case 'mysql':
    case 'mysqli':
      break;
  }

i decide to use "boolean" becouse if I use "tinyint(1)" it will be mean that we don't utilize PostgreSQL type "boolean" witch may be more efficient for this database.

To use this module with optionwidgets.module we need to add "boolean" type like below:

/**
 * Implementation of hook_widget_info().
 */
function optionwidgets_widget_info() {
  return array(
    'options_select' => array(
      'label' => 'Select list',
      'field types' => array('text', 'number_integer', 'number_decimal', 'boolean'),
    ),
    'options_buttons' => array(
      'label' => 'Check boxes/radio buttons',
      'field types' => array('text', 'number_integer', 'number_decimal', 'boolean'),
    ),
  );
}

I'm not sure that my module is really needed. Please help my take a decision about developing this module.

Here are benefits that I can see:

• Easier to create fields - fields create by text or number modules need to have allowed values like 0/1 or true/false. In boolean module we have it at once. When we try to create many fields like that this can be useful.

Weak points:

• Not much better use of database - boolean use 1 byte, integer 4 bytes and varchar L + 1 bytes, where L is length of string (minimum 2 bytes for "Y" and "N"). I think it is poor benefit.
• Harder to definie how true/fase value should be present to users. If we use Improved handling for optionwidgets we can define which words ascribe to value true/false, for example 0|Yes, 1|No or 0|False, 1|True etc. This can be implement of course by 2 additional settings fields to define string for true and string for false. As we can see, "Easier to create fields" benefit mean that we type "No, Yes" instead of "0|No, 1|Yes" as allowed values.
• I am afraid that we will have new module to developing but very similar to existing integer or text modules. So should we developing it for above benefits?

this can be done with textfield in 5.x, and 6.x. It will not be added to 4.7.x-1.x.