View support

+1
views support, table view

Here's a patch against taxonomy_image.module. It's really basic right now but does the job - adds the Taxonomy Image: Image field for use in list and table views.

Also I originally created a new views_taxonomy_image.inc file, but can't figure out how to create new files via regular diff, but that may be a better way to go so that it's only included if Views is being used.

here's the actual patch.

Okay, one more try. This patch should work now - views caching was giving me a hard time.

Excellent work Brenda! Your patch worked well :)

My only request is the ability to add a link to the image, so that when it is displayed in a list.

I had a look at you code and wasn't sure of the best way of going about it.

Also, it would be good if we could use imagecache to make the image appear smaller than the configured size?

Thanks

Thanks, new requests should stay in their own thread. :) Those are things I've been working on as well, though...

Is this a patch against taxonomy_image or views? When I try to patch taxonomy_image.module I get a error: malformed patch at line 60, and it aborts

I am also getting a "malformed patch at line 60" error while patching.....
//TB

Hmm.. interesting. Try this patch.

patch -p0 < views_taxonomy_image_4.patch
patching file taxonomy_image.module
patch: **** malformed patch at line 67:

Okay, I guess I suck at this patching stuff.. this one is true and tested multiple times!

That works well (I actually applied the other patch manually, too, but I tested the new patch with the original.)

I added imagecache support, and realized that it'd be really cool to put that directly in the view dialog (select imagecache profile, as link, as image.) I also realized that it might be better to remove the the sizing stuff from the taxonomy_image admin dialog, so it just uses original and imagecache profiles. I can't decide if this is something I should patch into this module (there would be only a few original functions left) or just make a new module.

What do people think?

Discovered the module today.

The first thing that struck me after installing was the fact there would be another place to set image sizes when using views, and imagecache.

I imagine people could be using this without imagecache and views, so a new version requiring views may confuse people and increase the amount of maintenance.

Is it possible to offer the option to allow imagecache to override the taxonomy_image sizing for people using views?
It would be great to get a 'Taxonomy image field' to show up in the 'edit view' page, along with options for using imagecache sizes. The patch posted @12 doesn't work for me (I don't get a 'taxonomy image' field in my views)

PS The views_taxonomy_image_5.patch replaces the closing php tag '?>', but doesn't add one to the end. Is this correct?

Drew

Drew, as per Drupal coding standards the last ?> is left out - so yes, that is correct. Also, you may be having some views caching issues which is why it isn't showing up yet. You can try truncating your cache_views table.

I actually did some imagecache work on this module myself, so I would be curious to see any work done on that front. The way the images are now, they're just forcefully resized through weight and height tags, the image isn't actually resized. I definitely think imagecache is a good way to go, but should the module require it? I'm not sure...

Either way, should open a new issue to discuss this.

Brenda,

Thanks for clearing up the missing close tag. Clearing the views cache fixed it, thanks.

I'll open a new feature request.

Drew

I made a patch that does views and imagecache optionally, with or without links to the term:
http://drupal.org/node/195548

@konsumer - if your patch includes this one, you should mark this as a duplicate.

I'm not sure if I should. Mine implements view support too, but also imagecache (if it's installed.) I'm cool with it either way, I guess I just don't know which is appropriate.

You said you were building on this one, so one could assume that the code in this patch is also used in yours, making this a duplicate. It also means I only have to review one patch instead of two. There is a greater likelihood if getting them both that way.