Marketpath CMS Developer Tutorial Series

Unstructured Data

Last Updated 3/6/2018

Unstructured data exponentially increases the capabilities of Marketpath CMS, and understanding the options available to you as a template developer will enable you to fully capitalize on the opportunities that custom fields on entities and pages, datastores, and custom site settings make available.

Unstructured data will vary from site to site because it is defined by template developers and not by Marketpath. The primary ways that Marketpath CMS provides to define and utilize unstructured data are custom fields on entities and pages, datastores, and custom site settings.

A word of caution before we explore each type of unstructured data - it is possible (and quite easy) to overdo it when it comes to unstructured data, and it does not matter if your site has unlimited capability if it is difficult to use. Wherever possible, you should focus your efforts on usability as well as the end result - which may mean taking advantage of some advanced functionality that we make available but it may also mean simplifying your website breakdown to include fewer or more discreet fields.

Custom Fields

Custom fields on both entities and pages are defined at the template level. By default custom fields are saved on the page, but the template developer can choose to store custom fields on the entity instead - thereby making them accessible wherever the entity is accessed.

Due to the nature of unstructured data, there are a number of things that template developers should be aware of when defining custom fields:

  1. When a template developer defines custom fields, he/she may (and should) group multiple fields together in order to make it more intuitive when entering data. When the custom fields are accessed, however, the order and grouping of fields is inconsequential.
  2. A template developer may choose to mark a field as "required", which will prevent users from being able to save the page until that field has been entered. They may also add validation to a field to restrict input to a specific format (eg: enter an integer or a decimal number). Although we do our best to enforce the validation rules created by the template developer, there are intentional and unintentional ways around these measures which may allow users to bypass them. As such, template developers should still validate their fields before displaying them (typically utilizing code such as {% if field.is_valid %}).
  3. We do our best to include custom fields from partial templates, but we are limited in how we can detect partial templates to include custom fields from. We call these, "compiled templates." In short compiled templates are templates included using {% include "template_name" %}. The main limitation is that compiled templates do not include templates assigned to a variable (eg: {% assign template = "template_name" %}{% include template %} or {% include page.sidebar_template %}). Although dynamically included templates will be included, any custom fields defined by them will not be automatically included in pages created using the parent template.

Datastores

Datastores are an interesting combination of structured and unstructured data. While there are a few core fields on every datastore item, the purpose is to allow developers to define their own data structure that every datastore item utilizes.

When a developer creates a datastore, they should add fields to it in a similar manner that they would add custom fields to a template. Some of the same limitations apply to datastore fields as to custom fields - including field grouping and required/validated fields. One of the main differences between datastores and custom fields is that it is much easier to query datastore items and to make datastore items selectable in custom fields and other datastores.

If a custom schema isn't enough, datastore items also have the ability to utilize custom fields just like every other entity in the CMS.

Custom Site Settings

Custom Site Settings are defined on a site-wide basis. This serves two purposes. First, it makes it easy to change the way the site works or is displayed with a single action and without modifying any code (eg: selecting a main menu or changing the logo). Second, since custom site settings can be exported and imported from site to site, it makes it easier to create reusable and customizable components without requiring a developer to modify templates on sites that the components are imported into.

Developers should e aware that even if they define a default value for a custom site setting, it will not be available on the live site until someone edits and publishes the site template settings.

Also, since custom site settings can be exported and imported between sites, developers should be aware of possible naming conflicts and should name their settings to avoid those conflicts. The easiest way to accomplish this is to use a consistent prefix for your settings (eg: if you company is "XYZ Corp" you might prefix all settings with "xyzcorp_" to make them unique.

A final note on custom site settings: regardless of where or when the setting was defined, custom site settings are always displayed under site template settings in alphabetical order. Be careful if you attempt to use this to your advantage so that you do not inadvertently make things more complicated than necessary when settings are imported from other sites.


---- End of Lesson ----

Question? Correction?

Let's work together to make our documentation as helpful as possible.

What is your name? 
What is your email address? 
Feedback: