We have some simple blocks that make up various lists and grids. Each parent list/grid block accepts any number of child blocks of specific types to render output. Using the child blocks outside of the parent listing context does not make sense and we'd prefer to prevent an editor from even selecting those types of child blocks outside of editing the parent block. Is this possible?
Parent List Block - Child List Item - Child List Item - Child List item
Editor should not be able to make a standalone Child List Item, and we'd prefer those not show up in block type selection unless they are creating a new block from inside the Parent List Block's content area.
Any direction on this is appreciated - and if there's a suggestion on a different pattern to accomplish this type of thing, we are receptive to that as well.
If I understand the requirements correctly, you have a content area which you would like to restrict to a single block type and you would like to ensure that block can't be created directly in the blocks panel and so can only be created in the "for this page/block" folder. I've not tried this in CMS 12 but I answered a similar question for CMS 11 and I suspect the same approach could be taken here. The CMS 11 answer is here:
In summary, the approach involves intercepting the ContentTypeAvailabilityService and, when returning the list of available content types the user can create, checking whether the block is to be created in the assets section and, if so, removing the restricted block type. That way, the user can only create a block of that type when clicking the "create new" link in the content area (or creating it directly under "for this page/block"). Beyond that, you'd just need to restrict the ContentArea using a [AllowedTypes(typeof(MyChildItemBlock))] attribute.
You could probably tweak/extend that approach to look at the AllowedTypes attribute and only include your block type if it's in the list of allowed types but that's not something I've looked into so don't quote me on that.
To answer the second part of the question. Your alternative would be to use a generic property list to represent your grid data. Just by way of a warning - generic property lists aren't officially supported but they've been around for quite a while and are widely used. These list properties work well for lists of objects with relatively small values (e.g. string, int, ContentReference, etc.) they're not so good for XHtmlString values and similar. That's not so much due to technical constraints, it's just that the UI is a bit messy when you have large amounts of data in a single field. You also can't apply visitor groups or display options to those list items so, if that's a requirement, you're better off with a ContentArea & blocks.
Hey, Paul - thank you! I think this is exactly what I was looking for. I'll give it a go in 12. Many thanks!