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;
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.
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.
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.
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
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).