Some third party modules may want to add file metadata for use in a field formatter, but not allow the user to select that metadata type for display in it's own column. For example, the test_id for a PIFT test.

We should provide a way for metadata to flag when it should not be included as a display option.

Comments

jthorson’s picture

jthorson CreditAttribution: jthorson commented
Status: Active » Fixed

Committed to 7.x-1.x as http://drupalcode.org/project/extended_file_field.git/commit/5609ac7509a...

dww’s picture

dww
we/he/they
CreditAttribution: dww commented
Status: Fixed » Needs work

extended_file_field.api.php needs a patch, too.

Thanks,
-Derek

dww’s picture

dww
we/he/they
CreditAttribution: dww commented

While you're at it, it wouldn't hurt to explain why you would add metadata that can't be displayed. I'm having a bit of trouble understanding why PIFT wants/needs to go through the trouble to define the test id as a full-blown file metadata column. If you just want to stash something in $items so other parts of yourself see it, why not just put it in '#test_id' or whatever? Can you explain (preferably in the PHP doc) why we actually want this?

Thanks!
-Derek

jthorson’s picture

jthorson CreditAttribution: jthorson commented

That (i.e. #test_id) may yet happen ... Currently, I've got each element from the pift_test table stored as it's own metadata entry; just to get to get something working initially.

My next step was to consolidate things down to a single 'pift' entry, or maybe two (one for results and one for operations).

As far as use cases for non-displayed metadata ... I might have to stretch a bit for that one. For me, it was having 'test_id' available as an input to the formatter for other fields. Throwing it into '#test_id' in the alter() hook works just as well, but I like the convenience of having all of a module's added metadata listed in hook_extended_file_field_metadata_types(); as opposed to having parts of it buried within hook_extended_file_field_items_alter() ...

For a contrived example, imagine we have a "result" field which displays "plugin1_result" and/or "plugin2_result" depending on the file; where "plugin1_result" and "plugin2_result" each have their own formatters ... we may wish to configure "plugin1_result" and "plugin2_result" as non-displayable, and have the "result" field formatter act as a proxy or aggregator for the appropriate plugins; calling each plugin-specific formatter as appropriate (where it's getting the formatters from the metadata_types() definitions).

Once I've actually worked on this a bit more (I'm still not convinced myself!), I'll add something to the api docs.

dww’s picture

dww
we/he/they
CreditAttribution: dww commented
Issue tags: -project

Cool thanks. I'm still unconvinced, but I'll await your update before I pass judgement on this issue. ;)

I think it's very safe to say that Project* itself doesn't care about this, so I'm untagging that. If you want/need it for testbot, that's up to you. :)

Cheers,
-Derek

dww’s picture

dww
we/he/they
CreditAttribution: dww commented

Ping? Any news? I still think this is bogus. ;) Can we revert this commit or do we actually need this for some reason? If we need it, can you explain why (either here or in the API docs)?

Thanks!
-Derek

jthorson’s picture

jthorson CreditAttribution: jthorson commented

I'm not currently using it for PIFT ... at least yet. But go ahead and pull it, and I'll explicitly add $test['test_id'] in the alter() call (or rather, already am).

jthorson’s picture

jthorson CreditAttribution: jthorson commented
Status: Needs work » Closed (won't fix)

Reverted in http://drupalcode.org/project/extended_file_field.git/commit/9185835cf6a....

dww’s picture

dww
we/he/they
CreditAttribution: dww commented

Thanks!

  • Commit 5609ac7 on 7.x-1.x, empty-file-2150029 by jthorson: 
    [#1976144] by jthorson: Allow metadata types to flag when not intended...
  • Commit 9185835 on 7.x-1.x, empty-file-2150029 by jthorson:
    [#1976144] by jthorson: Reverted commit 5609ac75