Random entity and config notes cut from Major module chapter

Nor is this export necessarily for the commonly accepted need to export the configuration of entities' bundles and their fields (although, to make things more confusing, fago's main use case is to make bundle definitions into entities)

If two messages apply to one form element, then both apply.

A multivalue form ID field.

Also ideally, that export would live only in code if the UI were never needed. On this point, unfortunately, Entity API always automatically imports to the database, rather than reading from code at runtime.

From a hook_schema() for an entity:

<?php
      'status' => array(
        'description' => 'Boolean indicating whether the form message is active.',
        'type' => 'int', // taken from node.install, why is this not tinyint?
        'not null' => TRUE,
        'default' => 1,
      ),
?>

The 'revision table' is the same, though we only need to have it at all because we want our entity to have revisions.

Now we get to an exciting part- defining a form for editing our entities. As long as it is named after our entity type (the name of this type of entity plus 'form') Entity API will automatically pick it up. (Here it would seem that my naming the entity type the same name as the module was not a good idea, as module-name plus anything is at risk for hook collision- and indeed, there is hook_form(), but it is only called for modules implementing node types, which contributed modules are unlikely to do.)

If we provide a content type, Drupal core and other modules can automatically add fields to it. If we create our own entity, we can make it fieldable, too.