If you see the following code from views/filefield_handler_views_data.inc you should note the "TODO." It would be great if this were fixed. I believe it would fix #600594: Integration with Views? Addendum in the imagefield_extended module's queue and allow many other modules that use the data field to be more extensible.

Comments

Thanks for filing an issue for tracking this issue. The question is how should this actually be implemented? My guess is that we'll need a hook like hook_filefield_data() that would report the name of values stored in the 'data' column.

Hmm, yeah that makes things more challenging. It also means that FileField's existing Views integration won't work with the data added by ImageField Extended without some modification. However if ImageField Extended is consistent with its structure, I would probably be fine with a simple check like this:

yes, in my experience the 'body' is consistently used in the structure and should work the way you wrote above. This will cover getting it working within filefield I think and then I can try to reference whatever hook you decide on over in imagefield_extended. Once you make a decision on the implementation I will post a patch following the decision here to the imagefield_extended module and that should really solidify data on filefields being used in views.

Subscribe: Thx quicksketch & nicholas.alipaz, it will be nice to get this feature request resolved in my queue.

@quicksketch - the module, ImageField Extended was extended to use the cck alter hooks and is based on the FileField rather than ImageField now, with no custom widget [sick of requests to extend to accommodate other modules]. I will wait until the Drupal 7 port before renaming it, but the same functionality should be automatically included with any ImageField / FileField. I still have to look at the Drupal 7 fields Image and File to see what this means.

Is there any need for expanding ImageField Extended for other fields? I think that there has only once been a single request for something other than a checkbox or textfield, a select list. If so, any recommendations on the need for these. I think keeping only 1 to 1 relationships will be a definite so it will not complicate any Views integration issues.

Anyway open to suggestions, you can use my contact form to send through your thoughts.

I would probably discourage extending the functionality of ImageField Extended to other fields. ImageField Extended is just a stop-gap measure until the CCK project gets Multifields/Multigroups figured out (it's actually already in the 3.x version, but there's a big question about what to do since Multifields are not in Drupal 7).

Speaking of Drupal 7, you'll find that ImageField Extended is going to have quite a hard time because the is no longer a "data" column at all, so you can't just tack on extra information like you can currently. I'm not sure if ImageField Extended is even going to be possible in Drupal 7. It certainly is going to need an entirely different approach, since it's going to have to maintain it's own schema.

Here is a reworking for the filefield_handler_field_data.inc which seems to be working on my system. I created no hooks, just did some smart discovery to see what labels are available in the database and then do some checks to allow getting their values properly.

Is there are way to extend Filefield's filefield_handler_field_data class by ImageField Extended to enable this functionality? I don't believe Filefield maintainer will make changes in code just to satisfy Imagefield Extended data structure (body, format, formatted)...

Also, the issue is not that imagefield_extended needs to support views, it is that all modules that extend filefields data should be supported in views by filefield if they follow a predetermined structure.

Nicholas, I agree that standardized approch is desirable. What I wanted to say is that body, format and formatted keys within data array is something that for now is specific to Imagefield Extended only. On the other hand it gives other modules an opportunity to reach Filefield Views field handler at least for these fields.

As far as I know, ImageField Extended is pretty much the only module that saves additional user-facing data in the data column. Generally I don't encourage using the data column at all, since it's a dirty hack more than something that should be widely used. If you needed to sort/filter on that data, clearly you'd need an additional column or table. Yet another reason why "data" doesn't exist in Drupal 7. I don't really care what we do with the data column, because we don't need to think about long-term consequences because it's already dead.

Although I very much would love the funcionality of this issue, I think a hook (like in #1) is much better approch rather than for Filefield to search (in a hackish way, I'd say) for keys to show. Other modules implement the hook to let Filefield know what keys they have.

Also, body, format and formatted might also be the model of what Filefield looks after in Views handler render() function.

quicksketch, you have any comments on this? I didn't feel it was "hackish" but perhaps I am wrong. I mean those keys are going to be where they are whether we provide a hook or we search for them. And like quicksketch said, "I don't really care what we do with the data column, because we don't need to think about long-term consequences because it's already dead."

quicksketch, if you would prefer an alternative approach then please describe and I will see what I can do. The only issue I see with the hooks is the time to adopt the new hooks in other modules. I am under a deadline and needed to go with my patch for one site, but can change later if this changes and other modules follow suit.

If we want to be flexible (aka "clean") about it, then we should indeed make not one but two hooks. One hook that returns a list of items within the 'data' column, and then another hook that actually displays data when requested. So in other words we should have an additional hook that handles something like this:

I think I may have missed some sguiggly brackets in my mysql statements {}. If your database has a prefix then this will not work. I am not going to rework the patch since it is not the way the guys here want to do it.

This patch adds the new hook for hook_filefield_data_info(), as well as the utility function filefield_data_value(), which can be used to print out a value given a portion of the $item['data'] array, such as $item['data']['description']. Since FileField and ImageField both just contain plain-text strings for its data, this data is simply passed through check_plain() and needs no specialized function.

I've gone ahead and committed this patch, please let me know if any changes look like they're necessary to assist ImageField Extended or other modules that utilize the $data column.

Also attached is the patch to ImageField which defines ImageField's "alt" and "title" columns. Both patches will be included in the 3.8 version of both modules.

I was attempting to try out the patches and look into patching imagefield_extended but the patch didn't complete. I have attached my rejected parts from the patch. I did not test further due to the rejects.

You don't need to try out the patches, they have already been included in FileField 3.8 and 3.9. The only thing that needs patching in the current version of FileField is the small typo posted in #37, which won't affect functionality.

As per the ImageField Extended support for this patch see #600594: Integration with Views? Addendum which is still to be implemented (eg: to implement the new hook). I'm only got marginal internet access, and limited time as we make our way down the eastern central american coast, so I personally haven't the time to fix this issue, but I am open to having co-contributors for IF Extended if anyone wants to speed things up. Ping this thread if your interested - #927738: Co-maintainers. Only precondition is that you have had experience with at least one other Drupal module so that you understand the protocol for CVS, etc.