Custom fields schema

[Gervase Markham]

Kevin Benton wrote:
> It seems to me that any discussion of custom fields ought to include
> existing fields and handle them all in a unified approach.

I would be extremely wary of this approach, because it unnecessarily 
increases the work involved in the initial patch. Why not implement 
custom fields, and then port existing fields over as and when?

? In my view, the
> best way to do this would be to define every field in a fields table, and
> specify formatting / location, etc. in the table.  

Absolutely not :-). Formatting and location live in templates. As Joel 
suggests, we need a system which deals with unknown fields but also 
allows specific placing of known fields.

For example, unknown text fields would just be appended to the list of 
four we have now, and unknown dropdown fields would probably go down the 
right somewhere. It doesn't have to look pretty, it just has to work - 
if an admin wants pretty, they can do explicit positioning. Hopefully 
Kiko's UI rewrite will take these issues into account.

> I would hope that there
> would even be a place where that table would have a definition for certain
> types of handlers (subs) associated with each field.  

I think such an association would work better using a code plugin system 
  - but again, that's way down the line. Version 1 should not include 
the ability for admins to define new field _types_.

I can see the use of a validation regex for text fields, though.

Gerv