(which happened on my local harddisk, so you didn't notice the revert at all)

filefield.formatter.inc and filefield.theme.inc work completely
with declarational 'file' properties in the various hooks,
whereas filefield.widget.inc still needs to be included manually.

stumbled over a few instances where the former is suboptimal.
Also, pass possible file formatter settings to the theme function.

we don't need that as it's given in the function name anyways.

multiple file widget specific ones. In tandem with that, add
file formatter settings to the field settings. Let's see if it works.

Also, make hook_file_widget_info() more like hook_file_formatter_info()
so that the array key doesn't specify the form element but is merely an
arbitrary key, with the need to be unique only inside each module.

and have a checkbox to enable/disable them.

The latter comes with additional functionality in terms of a validator
that only accepts files when any enabled widget handles it.
a.k.a. easy mimetype based upload restrictions. Makes it a breeze
to have image-only filefields without specifying the allowed extensions.

which is the only place where it's actually used.
It had kind of an orphan status further down, which I didn't like.

also hides behind the moving table header. Yeah, simpler is always better.

Also, for consistency, files are converted to objects (and back, in case)
every time they are passed to other modules.

Plus the usual minor cleanups and documentation fixes.

(load, save_upload, save, delete).

let's rather use '#default_value' where I stored the file.

specify their own validators.

'insert' and 'update' hooks for hook_file().

Also make sure that we can pass by reference in any case (so that modules
can insert properties on $op = 'load'), and adapt some style bits to
core's style conventions.

which the widgets are added to. Therefore, the original unbuilt form
should be passed, not the built one that is going to be scrapped.

Thanks to yched for a hint into the right direction (form_clear_id())
and fago for bringing to my attention that script tags can also be
inserted in the HTML body and are executed instantly.

Take that, JavaScript! Hah.

Also (which took far more time), change the AHAH callback so that it gets
its replacement element from CCK instead of constructing it directly.
Not only does that merge stuff like '#required' into the element but
it also gets rid of a theming bug. That's how I like it :)

the same objective isn't coded twice. As a downside, doing it this way
will not squeeze every last inch of CPU cycles out of this loop. Whatever.

CCK checks for itself before calling it, but who knows how it gets abused
in evil other ways, so let's be prepared for that situation.

should display a file or not, in case they're not using the regular
CCK formatters. Since I removed the access check from theme_filefield(),
this function's premier use is probably to salve my conscience.

Right. So add a few more.

for whatever reason. Not that I like writing such text, but hey, these
were the last two @todo items in filefield.module. Coolio.

The even better news is that I've been able to get completely rid
of the annoying 'view filefield uploads' permission by replacing it
with the more fine-grained field-level permissions from content_permissions
which ships with CCK 6.x.

The new code makes our hook_file_download() a bit more complex,
but on the other hand only cares about files that are actually
contained in at least one file field. Yay for correctness and flexibility!

* Use an error string similar to what Drupal core is using.
* Passive JavaScript errors (in a red error box) instead of alert().

  than this, only CSS gurus should be able to improve it even more.

* On the coding side, file edit widgets are now real form elements.
  That means no buttons for such widgets, but instead they can come up
  with their own value callbacks and widget theme functions.
  Plus I now have them in their walled garden where they belong.

Includes a bit more modularization of the uploading/deletion code.

Known bugs:
* Uploads work in Firefox but not in Konqueror, that is a regression
  compared to the D5 version. An ahah.js bug? (Drupal isn't even invoked.)
* The AHAH submit-replacement behaviour won't attach to the new form,
  it seems. I experienced the same thing with the CCK "add more" button,
  let's have a look what goes wrong there.

* Re-add '#name' properties for the buttons, so that the right one
  is selected on submit.
* Scrap the broken condition (using a wrong, previous variable name)
  so that the replaced file is added to the form state again on uploading.

  That way we can encapsulate as much as possible, and that's good for
  grouping the code. Consequently, widget code order is now sane at last:
  first comes hook_widget() which decides between upload and edit widget,
  then comes the upload widget, and then comes the edit widget.
  Finally some structure where I immediately find stuff.

* Move file uploading from the value callback to the submit callback.
  I'm pretty convinced that we don't want to upload selected files
  if *any* button is pressed (not just the "Upload" button).

* Rename $fieldname to $field_name, like used in core CCK code.

Nice side effect: more filefield-classed divs for detailed themeability.