Advanced Dynamic Data / Dynamic Content - Understanding Content Type Scopes

In this blog I want to give you a deeper understanding of Dynamic Data (also called Dynamic Content - though that's not the same thing). It' a level 300 briefing so it's meant more for more experienced users. 

We'll start with the core problem and build up from that. A content-type defines what a piece of content (also called an Entity) should contain. A few examples: 

1. A "Person" content-type might contain first-name, last-name, birthday, etc. 
2. A "Product" content-type might contain a product number, price, etc.  
3. A "ImageMetadata" content-type might contain the file itself, a title, created-date etc.  
4. A "Page" content-type might contain the url, title, and permissions…  
5. …while the "Permission" content-type might contain the who (group/person) and effective permission (read/write) 

This feels clear, right? Let's go a step deeper: 

1. A system component like a view / template must also be defined, with information like name, template-file etc. Let's call this content-type "TemplateDefinition"  
2. All fields of a content-type (like the first-name or birthday) have some common configuration like "Label" and "Description" - this information must be stored somewhere, and should ideally also be multi-language, versioned etc. - so this too should be defined in a content-type which we'll call "@All" - for Attribute-All  
3. The AmountOfKids of a person may need some configuration just for the number like minumum 0, maximum 64 (world record) - which should not be in a @All content-type. So let's say this is stored in a content-type "@Number"  
4. And the pipeline-configuration for the query "Get all references of the category in URL" must also be stored in a (actually various) content-types. Let's call that "PipelineConfiguration" 

This all seems straight forward and like basic database table design with a bit of "Dynamic" added. But if the normal user would see all the 50+ content-types needed for a full system to work, it would get very, very confusing. So it would scare the users, and very likely the user would change something (like the definition for @All) which she should never ever touch. 

This is why we introduced Scopes in 2sxc from the very beginning - and we kept them secret because we figured people don't need to understand this. But just recently I discussed sharing content-types (another topic for another blog) with Benoit and realized that keeping this a secret will prevent people from fully using 2sxc - so in 2sxc 8 we're coming out :). 

What is the scope? 

Technically it's just a text-value which each content-type has. Since the UI always retrieves content-types of a specific scope ("2SexyContent" by default), the user will never see the other content-types. Internally it also has a few affects - so the UI will always look for attribute-definitions in the System-scope.

The 4 Main Scopes 

As of now, we have the following scopes 

• System - this contains the basic content-types like everything needed to define attributes (@All, @String, @string-dropdown, etc.). In general everything which the EAV-System (entity/attribute/value) provides is found in here. So this subsystem knows nothing about dnn or 2sxc, it's kind of like the engine or database behind all this  
• SexyContent - containing everything you usually see - so the "SimpleContent" or things like that are found here. This is the default scope.  
• 2SexyContent-System - here we keep system content-types specific to 2sxc - like the content-type for template-definitions  
• 2SexyContent-App - content-types just for the app-configuration. Specifically the content-type AppSettings and AppResources, of which each app usually just has 1 content-item (entity) 

Looking at Content-Types of another Scope 

2sic 8 has a new advanced mode in the admin-area which you can get by Ctrl-Clicking anywhere. The round button is for changing scopes - type the desired scope name and see what comes. 

Understanding what you see in the System-Scope 

Most content-types will tell you they exist (like @String) and that there are many entities of this type which you can also edit. You'll also notice that most content-types cannot be reconfigured. This is because they are Ghost-Content-Types which are shared from a central definition (yes, another secret functionality I'll blog about soon). They exist here merely as an anchor for storing content-items, but the definition cannot be changed inside your app. You can recognize Ghost-Content-Types by the special icon and the fact that you cannot edit the field-definitions. 

Note that most of the data here is metadata for something. So looking at items of @String or even editing it can have funny effects, because each item of the type @String is used to configure the input of a string-type. Metadata-items can be recognized by the tag-icon beside it. You can see what object is being enhanced by hovering over the tag. And yes - Metadata is another one of the secret features I'll have to blog about sometime :). 

 So I hope this gives you a deeper understanding of the data-structures and possibilities in the EAV / 2sxc. I promise to blog about metadata, shared and ghost content-types as well as creating custom input fields soon. 

Love from Japan,
iJungleboy