I've put a big time on this, but that is for it to be done 'right', the block should have some mechanism to relay rendering modes through to the requested content type.

It could be done 'wrong' in about 40 minutes, and probably that would be fine.

It's just on here I'm thinking about long-term architecture.

Either technique may be sponsored.

well, it would certainly be better that it be done right so that it meshes long-term with where Composr is headed.

The truly ideal situation (which is much more than 8 hours, probably more like 2 weeks) is to rearchitect how content is displayed in Composr. In v9 I have tidied it up so there is a consistent naming scheme for boxes. But what we ideally want is a common API used by all content types, for all rendering modes. For any content type you could ask for:
- A particular entry (row) to show in a box (currently possible - awards).
- A particular set of entries (rows) to show in a sortable table.
- A particular set of entries (rows) to show as a collection (the content type defines what that might be, e.g. a grid, or just a series of sequential boxes). The API would also allow you could request a more specific rendering type which corresponds to the different catalogue rendering types (this only applies to catalogues - other content types don't need it). Pagination support here.
- A particular set of entries (rows) ready for insertion into a carousel.

All the modules would use this API. In essence module code currently dealing with showing entries in categories (and also listing subcategories) would be abstracted out and put in as implementations of the API. Then we can expose that back to the modules, to main_multi_content, and to the search module (allows better display of faceted search results).

There is currently non-clarity regarding how boxes work. Is a category view a collection of boxes stuck together, or are boxes what are stuck together with a box around it? Currently it varies from content-type-to-content-type. Ideally we would have each content type having 3 templates:
- Raw
- Standalone box
- Box in sequence
In most cases the latter 2 would do a straight Tempcode INCLUDE of the raw one, perhaps putting a box around it. This stops us having to copy&paste and set sensible defaults, but gains significant flexibility in themeing.

While I'm thinking about this, other export views would be helpful, Composr XML (for syndication), RSS, RDF formats, etc. Probably quite a lot could be rolled in with this. A lot of this was considered a while ago for the short-lived v8 branch (not the v8 we released). Then one starts thinking about imports, supplying data to the functions from different sources, with a translation layer - that then leads to database abstraction, syndication possibilities, etc.
One step at a time ;).

Chris-

Regarding this bit:
"A particular set of entries (rows) to show as a collection (the content type defines what that might be, e.g. a grid, or just a series of sequential boxes). The API would also allow you could request a more specific rendering type which corresponds to the different catalogue rendering types (this only applies to catalogues - other content types don't need it). Pagination support here."

To be done right, would this not also extend to gallery displays?

Gallery displays don't need to have multiple rendering types like catalogues do, because we can design exactly how a gallery should look, whilst with a catalogue we have to think "well, depending on what the admin is trying to make, they might want to start off with something like one of these choices".

I appreciate that kind of contradicts the original posted issue here but it doesn't make sense to have "grid galleries", and "non-grid galleries", just galleries. So the real issue is rearchitecting the system to properly aggregate content in a consistent way so that if multiple rows are needed in main_multi_content, they are rendered with appropriate templating to allow idealised styling to occur (which would be a grid display for galleries because that's the ideal display).

This has been implemented in a different way to what is described here, but largely achieving the same goals.

There is now an improved system for standardised rendering of boxes for all content (including subcategory boxes), via the main_multi_content block. Most category screens are now using this.

There are lots of new options and flexibility in the main_multi_content block. You can pass in a rendering code (a GUID) that relays through to the templates, and this effectively allows you to do multiple different layouts for the same content.

We're not actually having separate defined rendering modes like "grid layout" and "sequential box layout" by default, but rather this can be achieved via CSS, in accordance with the GUID passing. The default layout will be sequential boxes, but it would be very easy to add a few lines of CSS to tell those boxes to float with a width, and hence to form a grid -- or to set things up to render within a table.

Some default templating will be provided to allow main_multi_content to put stuff in carousels, kind of as a worked example of the above.

This isn't being integrated with the catalogue render mode. Many of the old render blocks have been dropped (e.g. main_top_downloads), but main_cc_embed hasn't. We're going on the principle that certain kinds/spots for content will continue to be specialised, although always going through main_multi_content will be an option for people as that works as a BASELINE.

The full philosophy of how all the box rendering now fits together has been thoroughly documented.

The main work for all this (which has taken quite a few days) has been in creating consistency and replumbing things.

All this ties into AJAX - main_multi_content will paginate via AJAX, and more. So now the module code is linking through to main_multi_content (and also main_gallery_embed, main_cc_embed, and main_news), it provides a big bonus - these areas of screens are now autonomous, full page refreshes are not needed for browsing.

My discussion above regarding data export -- that is more of something for the proposed webdav support (#218), although it's likely it would be implemented with a set of parallel APIs very similar to the updated box APIs used here.