Make the file upload widget as flexible as the display formatter: alter hook, configurable table columns

Items for consideration
- add author
- PIFT testing status
- timestamps
- 'obsoletes x, y, & z' logic

Going to look at adding the author column while my drupal.org dev site rebuilds, just as a proof of concept for modifying the widget.

At first glance, it looks like adding the logic for this to extended_file_field_preprocess_file_widget_multiple() would work, but this logic would then need to be duplicated in extended_file_field_preprocess_extended_file_field_widget_multiple(). So as a first step, I suspect we need to have both of these redirect to a third (and common) function for the logic.

extended_file_field_modify_widget() perhaps?

Probably. :)

Here's a work in progress ...

Summary:
- Re-uses the hook_extended_file_field_metadata_types alter() call, allowing 3rd party modules to add metadata types to the field settings select box (which appears in the widget instance settings form).
- New hook_extended_file_field_widget_item_alter() call added, so that modules can add metadata to each file item within the widget. Currently called individually for each item; but we should be able to refactor this into a single call for the entire widget.
- New custom #process callback extended_file_field_widget_process() added to each file element within the widget. Callback is responsible for hosting the alter() call as well as rendering the individual metadata column cells for each file in the widget.
- Now exclusively using the extended_file_field_widget_multiple theme call, so that we can insert additional columns in addition to the 'remove' button tweaks.

Issues:
The act of uploading a file breaks it horribly, due to the loss of per-file uid data in the ajax processing. Will dig into this on Saturday/Sunday.

Forgot the patch. :)

Wow ... that one sure beat me up for a while!

While the initial edit form was easy enough to build the functionality for, it appears that every time you click the 'Upload' button, core throws out your file objects and replaces them with just the minimum form values (filename, weight, description, and display). This works fine for core; but try exposing additional metadata, and suddenly file object values which were there for the initial load disappear in the middle of the AJAX refresh.

I went back and tried a few different approaches ... $element['#pre_render'] was a bust, as even though I could add the metadata I wanted, for some reason it gets stripped out before the theme call. '#value_callback' overrides looked promising, but led to the same dead end ... as did another attempt at '#process' overrides. In the end, I gave up on trying to force core to generate a single item with the metadata I wanted inside of $element['#value'], $element['#default_value'], or $element['#file'] ... and ended up creating a composite of the three. Once I got that working, the next challenge was stripping away all the cruft I had added during my experimentation, and getting back down to the minimum necessary code again.

Key changes from #8:
- Moved the '#process' addition to hook_field_element_info_alter(), instead of form_alter().
- Changed the widget form_alter() to a form_WIDGET_TYPE_alter().
- Removed the 'hide operations column' setting, opting to automatically hide it if it's empty. (After moving to the single theme function, the column doesn't appear even while empty ... and from a UX perspective, having the 'hide operations' setting appear when you *uncheck* the 'show remove' checkbox in the field ui settings form felt awkward.)
- General code cleanups.

I still want to try and sort out a way to consolidate the hook_extended_file_field_widget_item_alter() calls into a single alter(); but wanted to save the 'working' patch before I started messing around with it any more.

Re-adding tag.

Committing to 7.x-1.x to avoid generating commit conflicts next week ... will add the items_alter() as a followup.

http://drupalcode.org/project/extended_file_field.git/commit/13f501fa1b8...

Followup opened at http://drupal.org/node/1970322.

Hmmm ... Back to NR for any required review followups. :)

My motivation behind rushing this in was due to the amount of code that's been touched, and the fact that I'll be less less active during the week than other folks who could be working on this ... it doesn't look like there are any outstanding patches currently under way in the queue, and I'd like to avoid the potential need for rerolls on this or any new work generated in the next week.

What? I'm sure I added it there ...

/me gives up on format-patch and goes back to git diff. ;)

"Show # hidden files" makes sense, but "Hide # hidden files" does not and in fact sounds really weird. I believe that it should be something like "Hide # obsolete files".

Yeah, sorry Derek, but I though that this was specific to this module and the widget it provides. Both issues you mention are specific to d.o (Project issue tracking actually) and its upgrade to D7. Extended File Field is meant to be used as a generic file upload widget though. Right?

Also, I thought that perhaps parts of #66484: Allow issues to be filed against multiple versions/branches. and #1171958: Allow files to be assigned to branch(es)/version(s) and thus tested against it could fit in this? I'm not saying that these should be handled by this module, but that we should help UI-wise (when uploading .patch files). We already added the hidden/visible functionality, perhaps we could also help this situation where people keep switching back and forth branches simply in order to trigger patch tests against the proper branch. It simply adds noise to the issue.

I can understand the confusion, but the current wording makes sense when you consider the context of the file widget ... you are editing the node, and the files are "Hidden" when the node is displayed; even though they are visible in the widget display itself.

I hesitate to switch to 'obsolete' because it is also use-case specific ... the widget allows you to turn off display of certain files, but it also allows you to turn it back on. The 'hidden' state may be temporary, in which case the file itself may still be relevant instead of obsolete.

I pondered this while writing the module, and the next-best descriptor I could think of is 'non-displayed'; which is virtually equivalent to 'hidden' (but a lot more awkward in practice).

In any case, if you'd like to continue the discussion beyond this, can we do it in a new issue so that it's titled appropriately and easier to find 6 months down the road when the topic comes up again? Thanks! :)