Blocks and IContent

Dejan Caric

Vote:

Hi,

Why blocks don't implement IContent interface?

All content repositories work with IContent interface. If I define my block like this:

[ContentType(GUID = "4d469f28-aa4d-47c4-9bf8-6819db87966a")]
public class MyBlock : BlockData
{
}

and want to implement IContent interface, then I must define all its members.

But if I don't implement IContent conterface, I'm able to do this:

public override ActionResult Index(MyBlock currentBlock)
{
    var contentLink = (currentBlock as IContent).ContentLink;
    ...
}

#119252

Mar 25, 2015 12:05

Marija Jemuovic

Vote:

Hi, Dejan,

The functionality behind the scenes is using mixins to achieve usage of blocks in two ways - as local and shared.

Local blocks are not IContent, they share the lifecycle of the page (they are not versioned separately either, not implementing IChangeTrackable, etc) and normally you see them grouped on the page, whereas the shared blocks exist on their own in the Assets tree.

Very good read on this is Joel's http://joelabrahamsson.com/episerver-7-content-pages-and-blocks/, then read about blocks, but I'd suggest reading about mixin functionality in general as well, since it's not so natural in C#.

You are not supposed to implement IContent, once the block is used, EPiServer determines this in runtime. Instead casting it in the controller is a way to go.

BR,

Marija

#119255

Mar 25, 2015 13:22

Dejan Caric

Vote:

Would you be so kind to explain me how this works under hood? Disassembled code or name of the class(es) where the magic happens would be nice :)

I didn't find much info in the SDK.

I would like to know how local blocks are saved into a database vs shared blocks, and why is it better to use mixins / proxies instead of using separate interfaces for local and shared block?

If local blocks are properties like any other page property (string, ContentArea, ContentArea, etc.), do they need to derive from BlockData? (they do, but in theory :) )
If I want to have two blocks (local and shared) that share the same set of properties, I would extract a common interface and keep it SOLID.

#119256

Mar 25, 2015 14:32

valdis

Vote:

We had cases when the same block was used as shared and as local. Class, template, everything was the same. So it makes sense to reuse that is needed.

#119263

Mar 25, 2015 15:45

Johan Björnfot

Vote:

As Marija said blocks is a special kind of content (compared to e.g. pages, folder or media) in the way that they can be used both as "local" blocks (where they are used as a property on e.g. a page) or "shared" blocks (where they have an own identity) which can be reused on several other content instance (e.g. through ContentAreas). i have tried to explained a bit how it works in the post

#119742

Apr 02, 2015 11:46

Dejan Caric

Vote:

Thank you all for your help. Now I understand why it's designed that way, and with help of SQL Profiler and .net reflector pro I understand how it works under the hood :)

Local and shared blocks concept is quite cool from developers perspective, but I never used them in production.
Editors / UX team always preferred to use shared blocks or properties grouped by tabs instead of local blocks (for example, a bunch of properties on Contact Person tab vs ContactPerson local block on content tab).

#119788

Apr 02, 2015 13:25