Page Creation Concepts (MIB3)
Media-iBox was designed to allow extensive customization. Pages in the CMS are defined as a stack of “Components”, visually displayed one below the other, each performing manipulation of a subset of data related to the current object.
As an example, the editing page of a Movie object could be defined using this system as:
- Form Component for editing the basic Movie Metadata
- Multiple Form Component for editing language-specific Movie Metadata
- List Component for assigning/unassigning Genres to the movie
- List Component showing all the Media Files for the movie, including preview
- List Component showing all the Images for the movie, including preview
- DMM Status Component showing the progress for the media ingestion
One of the key extensibility concepts of MIB3 is that, while we provide several “core” components covering a good amount of editing scenarios, it’s possible to develop custom per-project components and use them mixed in the page with the core components. So, as an example, you could modify the structure above to include custom components such as:
- Form Component for editing the basic Movie Metadata
- Multiple Form Component for editing language-specific Movie Metadata
- List Component for assigning/unassigning Genres to the movie
- List Component showing all the Media Files for the movie, including preview
- List Component showing all the Images for the movie, including preview
- DMM Status Component showing the progress for the media ingestion
- (Custom) Component connecting to the customer’s sales system reporting historical sale data for this movie
- (Custom) Component connecting to Google Analytics to display visiting data for this movie’s page
Custom components are not restricted to read-only information. They can also perform data persistence, and even save the data in the same database transaction as the other components, through usage of the MIB API’s batching model.
It’s a bit outside the scope of this document, but implementing a component consists in implementing a C# library with classes inheriting from one or more of the IComponent interfaces (IRenderableComponent, IRefreshableComponent, IPersistableComponent or IHandlerComponent). You may include .cshtml views, .js scripts or .css files with your component as well.
When creating a page in MIB you have three elements:
- Components, which are the individual building blocks for pages.
- Templates, which group and order components for exhibition.
- Pages, that take a template and apply configurations to create editing interfaces on the CMS.
While the discussion here is focused on MIB3, the previous version also works on a similar concept, though it uses a different naming.
- MIB3 <-> MIB2
- Component <-> Block
- Page <-> Quick Content / Quick List
There were no templates in MIB2, so you had to declare the individual components for each “Quick Content” you created.
Page Creation Data Model
While MIB3 performs all data management through the MIB API, it still possesses a small database attached it, that contains the page and template definitions for the user interface.
All objects in this database have both an ID field and a string-based unique identifier (“Key”). With exception of the page, that includes this identifier in the URL, this string-based unique identifier is only used to make database migrations easier to read and maintain, in particular in scenarios where you have multiple dev/hlg/prod environments with different IDs for each object.
MIB3UX_COMPONENTS
Lists all components available for the system.
- COMPONENT_KEY (varchar, not null)
- Secondary string-based unique identifier for the component.
- ASSEMBLY_NAME (varchar, null)
- Assembly (DLL) name for this component.
- If omitted it’s assumed this is a component from the “core” set.
- CLASS_NAME (varchar, not null)
- Class name for this component.
MIB3UX_TEMPLATES
Templates are reusable sets of ordered components.
- TEMPLATE_KEY (varchar, not null)
- Secondary string-based unique identifier for the template.
- HAS_ANCHOR_MENU (bit, null)
- Enables for this template the menu for showing/hiding parts of the page.
- Generally used in very long, complex pages.
MIB3UX_TEMPLATE_COMPONENTS
Stores the components of each particular template.
- TEMPLATE_COMPONENT_KEY (varchar, not null)
- Secondary string-based unique identifier for this instance of the component inside the template.
- This is often used when generating IDs for this component on the HTML sent to the browser, to avoid issues if there’s two instances of the same component in the page.
- ORDER (int, not null)
- Position of the component inside the template.
- COMPONENT_ID (int, not null, reference to MIB3UX_COMPONENTS.ID)
- ID of the component this record refers to.
- TEMPLATE_ID (int, not null, reference to MIB3UX_TEMPLATES.ID)
- ID of the template this record refers to.
MIB3UX_PAGES
Represents an URL inside the system. Pages are accessed through the route /Display/<page_key>.
- PAGE_KEY (varchar, not null)
- Secondary string-based unique identifier for the page.
- TEMPLATE_ID (int, not null, reference to MIB3UX_TEMPLATES.ID)
- ID of the template in use by this page.
MIB3UX_PAGE_CONFIGURATIONS
Stores configuration settings that apply to an entire page.
- CONFIGURATION_KEY (varchar, not null)
- Key for this configuration.
- CONFIGURATION_VALUE (varchar, not null)
- Value for this configuration.
- PAGE_ID (int, not null, reference to MIB3UX_PAGES.ID)
- ID of the page this record refers to.
MIB3UX_PAGE_COMPONENT_CONFIGURATIONS
Stores configuration settings that apply to specific components inside a page.
- CONFIGURATION_KEY (varchar, not null)
- Key for this configuration.
- CONFIGURATION_VALUE (varchar, not null)
- Value for this configuration.
- PAGE_ID (int, not null, reference to MIB3UX_PAGES.ID)
- ID of the page this record refers to.
- TEMPLATE_COMPONENT_ID (int, not null, reference to MIB3UX_TEMPLATE_COMPONENTS.ID)
- ID of the component this record refers to.