Storage structure for AJAX Form Messages

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

message location - a custom field?

so basically we have a form element entity, which can have fields of:
- form element id (this is not as simple as it sounds)
- form it is active on (multivalue)
- warning-only or blocker
- act-on (keypress or leaving element-- not sure if dropdowns are directly comprable, if keypress feasible for textareas, etc)
- message (initial) - highly optional
- message (error)
- message (ok)
oh god do we need token integration for the messages?
- 'validation' function to call (ok, this is a custom field, for sure!)

we either need a JavaScript field– add any arbitrary JS to the form– or we need to be able to point to other fields for (plugin-defined?) certain purposes and have some other aspect of the code figure out the JavaScript and add it. This is for taking the value of other fields into account. (For instance, for unique field combinations-- an automobile node cannot have the same status, color, and year as an existing automobile node. This gathering data from several fields is the hard part.

Pass it the other elements for which it must gather the values… if it is three fields that need to be unique and all three need to get its own and the others value, could we save repetition of javascript?

"on that click" go get certain other values

• context (array of other form element names

OK, the validation function gets passed an optional context array. Magic context array is going to make everything better.

First search for % (or *)
then search for example_%
and finally search for %_example

If someone wants a wildcard in the middle, they can file a feature request.

Why not store everything per-message?

For checks that involve multiple fields, such as multi-field uniqueness checks, it would seem that a single message with multiple fields would make sense. However, the message, even if placed in a neutral spot, should reference what field was just changed, so the message is per-field. Likewise the checking is field-specific, including when assessing a field's relationship to other fields.