Move Default Image code to ImageField module

From #434440: More Tokens:

I'd prefer not to add a new hook to FileField, considering I just spent a month removing all the custom hooks from FileField. See #397578: Uncouple ImageField from FileField Custom Hooks. If we need new hooks we should built them into CCK instead of FileField.

@quicksketch, you're definitely right. You've done a huge and impressive work with FileField and ImageField.

What I try to do (and it was only a bad-draft) is to let other modules "Extend" FileField. What I mean is: an Image is a sub-type of File, isn't it? A Video file is a sub-class of File... they share the base "file" attributes and extend them with others (say Title/Alt for Images; audio/video decoders info for Video).

My idea is to provide the same FIELD definition for all "Files" and let other Widgets (ImageField for example) extend them. Doing this we can re-use the base File code for handling upload/sharing/formatting and provide an API for extending basic FileField behavior with other data/info.

I've done this (not really clean and fully working code I know) provining, for the widget used for a particular FileField, the callback

MODULENAME_WIDGETNAME_filefield_sanitize()

here the extending module could, for example,
- provide default values for FileField
- provide token substitution (with full $node reference) for custom additional data

What we should get? That Views integration can work out-the-box for extender (virtual) fields and much more..

What do you think?

I don't think FileField is the right place to put these new APIs. Surely other field types could benefit from the same sort of extended APIs? They should be added to CCK, not FileField. Like I said, I just spent a month removing this EXACT same functionality from FileField. I'm not going to add new APIs to FileField when it's not the correct place to put them.

@quicksketch: I think that, for CCK added functionality, you're talking about #417122: Allow drupal_alter() on Field and Widget Settings.. right? :)

Heh, well I'd certainly like if #417122: Allow drupal_alter() on Field and Widget Settings would get in, but that patch won't help with this particular request. That patch only adds drupal_alter() to the field settings, and it can't affect the normal field operations like load, insert, update, or sanitize (note there is an API to add extra data, but not to affect data before it's inserted or sanitized.