Ferreteria/v0.3/usage/forms

I'm now finding that forms need to do I/O via methods other than database tables and HTML. For Cart records in VbzCart, it turns out to be useful to serialize the form data and store it in a single Cart field, which considerably simplifies the coding and reduces disk access (the old method required one disk access per form field, while serializing can be done once per entire form received or rendered).

What I'm thinking, then, is that we need to abstract connections as well as formats (which are already abstracted) -- so you could connect a given form with any two arbitrary I/O methods, e.g. a data table + HTML layout, or serialized field + HTML layout, or whatever other methodologies might be needed. The rest of the operations become simply input or output requests from these connections. To receive an HTML form and save it to a data table, you'd tell the HTML form connection to Fetch() the data from the $_POST into internal storage, and the data table connection to Store() the internal values out to the database.

As now, each connection type would have its own set of formats, and internal ("native") data would also have a type. Each connection type would have a default class for each native type. We might need to be more fine-grained about native types in order to make this work -- perhaps something like the MIME type/subtype system, where "type" actually changes the code used for the native object and the "subtype" (ignored by native classes) is there for connection types that have multiple classes for the given basic data type. (Example: booleans can be represented in SQL as either integers or bits, with the values being represented differently for each. Enums can be represented in HTML as drop-down selectors, radio buttons, or text fields. Timestamps have at least two major base field types in SQL, with multiple options for each.)