Currently we define the image
or icon
option for each section.
However, often I think it would make more sense if the page/blueprint would define itself how it is previewed, e.g. it shouldn’t be the section where a blog post is shown that defines that a blog post is previewed by the first image with the template “cover-image” - it should be the blog post itself that defines that relation.
This would also help for situations where mixed items are shown (e.g. search) to produce consistent previews.
I can imagine situations where you would still want to define some aspects on a per section basis (e.g. in this section show with ratio 2/3). So maybe the solution would be to take both into account:
(with the latter overwriting the former in that list).
Maybe also use this chance to combine image
and icon
into a unified preview
option - which we could use consistently in sections, model fields, search…
In “strict OOP”, the ‘preview’ would be a property of the ‘page’ object, so in order to keep encapsulation it should be responsible for deciding what that preview is. The ‘sections’, ‘tables’, etc. should merely ‘ask’ the object to provide its ‘preview’.
This could also mean that instead of providing an ‘image’ or ‘icon’, the object could return a ‘colour’ or ‘gradient’, or ‘none’.