Is there a canonical way to implement a lead image in content types?

I want to be able to use all my custom content types with the standard views for folders and collections; currently we have an album_view (that was renamed at some point and I can't find now on GitHub), a folder_summary_view (folders) and a thumbnail_view (collections) and all of them seem to use a different approach on showing the lead image.

On a quick test I see different behaviors: folder_sumary_view breaks sometimes, and thumbnail_view is way to slow if your collection returns many elements with many images inside.

Can we came up with a standard way of adding a lead image to content types that could work with any of those templates? Could it be based on implementing the ILeadImage interface?

Yeah, the ILeadImage behavior from plone.app.contenttypes is a good way to do it.

Listing templates should use the @@images view (from plone.app.imaging/plone.namedfile) to access image scales for display; it works for Archetypes and Dexterity and does not depend on the content type having anything special aside from the field.

Well, is not that easy; just take a look at this example:

I don't understand why I can't decorate methods inside the content type class.

We need to have a consistent way of doing things, also, we need to fix the getFoldersAndImages function in plone.app.collection; it is very expensive and is not cached.

Well, you didn't explain that you need special logic to find the image inside a container. Yeah, the behavior doesn't help with that.

I don't understand why I can't decorate methods inside the content type class.

Because Acquisition. When you use the @property decorator, it strips the object's Acquisition wrapper. So inside the method decorated like that 'self' will no longer know where it is in the site. Instead you can use the old Zope way of writing properties (from before properties existed in Python!):

from ComputedAttribute import ComputedAttribute

def _my_function(self):
    # do stuff here
my_function = ComputedAttribute(_my_function, 1)

We need to have a consistent way of doing things, also, we need to fix the getFoldersAndImages function in plone.app.collection; it is very expensive and is not cached.

Indeed, it looks like it does a separate catalog query for each container. If this is just to find an image to show for containers, maybe we should update an attribute on the container when images are added/removed inside it, so that there's an efficient way to read the current highlighted image.

slightly related: @hvelarde, have you seen the current refactorings of the standard views in plone.app.contenttypes 1.1.x and master branches, which work now with collections and folders: https://github.com/plone/plone.app.contenttypes/tree/master/plone/app/contenttypes/browser

Maybe not related at all, but as an idea............
,,,, I was hoping to use a widget to show images in templates, trying to avoid all the TAL scaling stuff.

Currently, it looks like this:

Unfortunately, I did not manage to put any logic in a .py-file (location error) so the image scale is taken from a helper view (this is not intended, and hopefully I will find a better way),

Anyway, it can be used like this:

@thet can you point me to a specific commit or PR?

pull-requests #202 (first master attempt), #212 (first 1.1.x attempt) and #216 (1.1.x) are related.

Is there a way to 'find' the @@images view when one only know the blob file ?
If you have a content view, context/@@images works. But if it is a listing view and/or a widget is used another approach is used (?).
When looking at the @@download_url (plone.namedfile), I see the same problem, which is 'fixed' by using the request (not context).
BUT; the download_url actually includes the view in the url, like
path/to/somewhere/view/something/@@download
instead of
/path/to/somewhere/something/@@download

I tried this with no luck; maybe later, when we finish the sites we are developing, I can dedicate a little bit more time.

and we need to document it; I just found this question from 2011 on SO on the same: