A little bit disappointed with boards

JohntheFish · April 26, 2023, 11:37am

Looks like this will be addressed in a subsequent v9 or v10.

Build Board Content out of Blocks and Containers Instead of Custom Slot Objects

opened 05:34PM - 24 Apr 23 UTC

Affects:Content Creators Affects:Developers Product Areas:Boards and Summary Templates Type:New Feature Enhancement:Level Of Effort:3 Enhancement:Quality of Life:3

### Description ## Board Template Updates Currently, boards have a mandato…ry Board template. In truth, we don't even always use these templates. For example, in one site our template is simply outputting 6 slots with no markup one right after another. This is silly. We should make these optional, with the only truly required thing in a template being a number of slots. ## Dynamic Slots But what about that? Hard-coding the number of slots for a Board was a stopgap solution in order to get to a shipping 1.0 product. Boards should be able to have the number of slots defined, but also changeable based on the instance of the board. ## Board Slot Templates Next up, we have the concept of Board slots. In Atomik, Board slot templates include the following * Blog Card * Blog Image Left * Blog Image Right * Blog Three Up * Blog Two Up In another site here are the ones we're using. * Two Up White Blue * Two Up White Orange * Two Up Blue White * Two Up Gray White etc... These names probably sound familiar - check out the containers defined in that same site: * Two Up White Blue * Two Up White Orange * Two Up Blue White * Two Up Gray White etc... Yes, there are other containers and templates defined here, but the core of the issue remains: there is very little difference between container templates and board slot templates. And when you actually look at the content contained within these it becomes even more egregious. Check out these board slot templates: * Image Left Stripe * Image Right Stripe The contents of these are the same: <section> <?php $slot->display(1); ?> </section> These template files exist only due to the rules being used to govern intelligent content placement within boards. Once these are all configured the results ensure that boards look nice – but at the moment such a setup is actively developer-hostile: developers have to create lots of stub templates and route content types between them in order to get things to work nicely. It's no wonder that few have tried. ### The Solution: Board Slot Templates become Containers It's time to do what we should have done in the beginning but just didn't have enough of a system to pull off: we need to unify board slot templates and containers. Instead of board slot templates being inserted into board slots, containers will be inserted into the slots, and blocks will be placed into those containers. As stated before, we've basically rebuilt Concrete CMS inside boards as a custom system that has none of the benefits and reusability of Concrete blocks outside of Boards. We need to change that. Beyond explaining the system to developers and some abstract concept of "cleaner code", why else would we do this? Simply put, by unifying these systems we're going to be able to integrate board contents into the larger Concrete ecosystem in some compelling ways. Read on for more information. There may be some metadata about containers that we need to track in order to make this work, but thankfully we can add this onto containers as a progressive enhancement. In order for a container to be available in a board, it needs to have a container controller. This enables the container to specify how many slots it has, etc... By making this optional we'll enable containers to be backward compatible, while updating the ones available in Atomik and Oxford Shirt to support this new paradigm. ## Content Slots Once content makes its way into a board's slot, we need to change how it's stored. Currently there's a custom table that joins board instance slots to blocks. These blocks are all instances of the special core_board_slot block type, which joins content objects to various summary templates. It's needlessly complicated. Instead the blocks that these instance slots join to will simply be instances of the core_container block type. Inside these containers will be real Concrete blocks. ## Summary Block in the Core In order to make this work, we will need to create an instance of the Summary block that we added to EW2 in the core. This should be done anyway - summary templares are a cool feature but without a block that exposes them they're only useful in boards - and if we want to treat board content like first class Concrete content we'll need to port this block over. ### Example _No response_