Block Groups vs IList<Block>

[i-love-code]

I'm working on an example of a site with a classic/legacy "hero slider" that has shared content across the site.

I first created a HeroBlockGroup with HeroBlock,

[BlockGroupType(Name = "Hero", IsUnlisted = true)]
[BlockItemType(typeof(Hero))]
public class HeroBlockGroup : BlockGroup
{
}

If you try to extend the StandardSite in Mvc.Web with that as a region:

[SiteType(Title = "Standard Site")]
public class StandardSite : SiteContent<StandardSite>
{
    [Region]
    public HtmlField Footer { get; set; }

    [Region]
    public HeroBlockGroup Hero { get; set; }
}

This doesn't pass the content type builder/resolution and the region is not displayed.

As a workaround, you can do

[SiteType(Title = "Standard Site")]
public class StandardSite : SiteContent<StandardSite>
{
    [Region]
    public HtmlField Footer { get; set; }

    [Region]
    public IList<Hero> Hero { get; set; }
}

It seems so similar, is there any reason why BlockGroup doesn't/can't render as a region? It would be great to have block groups be able to be used as inline region definitions.

[i-love-code]

Some use cases that this could be beneficial for:

• (The example above) A block group that may have one or more types of blocks allowed as a region of the SiteContent
• To add rigidity to page types, have a field/region be dedicated to a certain number of block types. Example: Advertisement Area/Column of a page, should only allow certain block types that are advertisement-driven or designed to fit in that area of the page

[i-love-code]

When looking at the code, in GetRegionType that attempts to parse the example above, it's only looking for things that are an IEnumerable or have fields inside of it. Since BlockGroup only has an IList inside of it, it's neither and fails to be rendered.

It would be ideal if this could render alike any other block, but I'm assuming there's more work than I'm anticipating to make that happen.

[tidyui]

Yes there’s a big difference in the data model between regions and blocks. Blocks are stored as a data type in the database, regions are just an id on the field table used for grouping the field data correctly when transforming the models.

We have several issues open with features for regions that could much more easily be achieved with blocks, and block groups have many benefits over list regions, one obvious being that a block group can both have global fields on the group itself and items with values of there own.

However, since it would require a completely different data model to store this information it would break backwards compability but it is something we could take into consideration for the new generic data model we’re looking at.

/Håkan

[firedog]

Similar to #952

[tidyui]

Exactly! For a more technical in-depth answer, regions are saved using the following data-structure for Pages (slightly simplified).

PageField
{
    Id
    PageId
    RegionId
    FieldId
    SortOrder
    Value
}

The fields RegionId & FieldId are used when mapping the correct field against the correct region. SortOrder is used for mapping List-regions. If we on the other hand take a look at blocks (again simplified).

Block
{
    Id
    ParentId?
}
BlockField
{
    Id
    BlockId
    FieldId
    SortOrder
    Value
}
PageBlock
{
    BlockId
    PageId
    SortOrder
}

Blocks were designed so they can be created without a Page or Post owning them (see #290) so they have their own entity. Also, a block group is in fact a block that has child blocks pointing to it with their ParentId field. This is also why a block group can have fields of their own and have child blocks with fields.

Regions were just designed to be a grouping of fields on Pages & Posts.

[tidyui]

This unfortunately can not be implemented given the current data model. The main reasons for this is:

1. A block group can have both fields and a collection of fields, a collection region can just be a collection
2. A block group can contain items of different types, a collection region needs to be fixed on one type, i.e IList<T>

Changing the data model to support these features, the second we've looked at in the past, would unfortunately break all backwards compatibility and be very hard to migrate.