entities

Update: Here is the code we currently use, abstracted into a helper function with lots of comments but it's really just two lines:

See Form Messages.

Principle: On a site with multiple administrators, "Configuration is Content".

Manifesto posted http://drupal.org/node/938368#comment-4286326

http://api.drupal.org/api/drupal/includes--common.inc/function/entity_form_field_validate/7

By using field storage, we get access to translation.

We've defined the info files, made them dependent on the core module. That was fun!

Caching is fun to implement, but try to hold off until you have all your functionality in place. As someone somewhere surely said (OK, it was Donald Knuth), "Premature optimization is the root of all evil."

We could define our form messages as a nested array analogous to menu definitions— a form ID,

Fields offer the advantage of understanding translation for user-entered data. Therefore, using fields, there's a potential

Karoly Negyesi (chx) mentioned in IRC "one thing people (like rszrama) is using entities is basically multigroup functionality." "Say, you have something like a line item in an invoice, needs a lot of fields, that becomes an entity. And it's not a node because a node has stuff like promote and sticky which does not apply."

Fields

borrowing from Barry Jaspan, http://www.archive.org/details/DrupalconDC2009-FieldAPIDrupal7