Content querying and content modeling training guides

With any content management platform, you must decide how to structure data. If you are a developer, you may feel tempted to leave content modeling totally in the hands of solution architects or project managers, but it is important to understand how modeling decisions affect both your development tasks and the ease of delivering a functional project.

When you design infrastructure-specific content types that exist within a digital experience platform like Xperience by Kentico, it is important to consider the strengths and friction points of that platform: will the design allow editors to easily work with the content? Does the platform have a straightforward way to query and display a given model, or will it create extra development work?

With the Training guides commerce implementation, our content modeling approach had the following goals:

• Store products in the Content hub, using page wrappers to display them in web channels
• Use separate content items to represent product variants
• Ensure developers can easily query products of multiple content types based on a variety of parameters
• Minimize unused, inapplicable fields during the editing process to prevent confusion

Let’s outline scenarios that prioritize editor usability and data querying efficiency, then examine the solution the Training guides model uses to balance them.

Choose a balanced modeling strategy

public bool ProductHasVariants(IProductSchema product)
{
    if (product is IProductParentSchema parentProduct)
    {
        return parentProduct.ProductParentSchemaVariants.Any();
    }

    return false;
}

private async Task<ProductViewModel> GetCatFoodViewModel(CatFood catFoodProduct, CatFoodVariant? catFoodVariant)
{
    // Shared logic that does most of the work based on shared schemas
    var model = await GetGenericProductViewModel(catFoodProduct, catFoodVariant);

    // Small addition to include a type-specific field that is not from a schema
    model.ProductOtherDetails = new HtmlString
            (("Ingredients:<br/>" + string.Join("<br/>", catFoodVariant?.CatFoodVariantFormulation
                .Select(formulation => formulation.PetFoodFormulationIngredients) ?? []))
            ?? string.Empty);

    return model;
}

Training guides commerce schemas

You likely noticed that the Training guides product model relies heavily on reusable field schemas. The schemas act as building blocks to create our individual product content types, and allow us to compose most of each content type with minimal type-specific fields. Let’s take a closer look at how they work.

Application

Let’s contextualize these schemas with an example. Imagine you are creating content types to represent T-shirt products and their variants. (We’ll use a ✓ icon to indicate that a given schema is broadly recommended, and a ? icon to indicate that a schema could apply depending on the given scenario.)

• T-shirt (parent product)
  • ✓ Product schema for basic name, image, etc.
  • ✓ Product parent schema so we can create variants for different sizes and colors
  • ? Product price schema to store price if all sizes and colors cost the same, and should not be possible to separately discount
  • ? Product shipping schema to set shipping info if the weight difference between shirt sizes is not large enough to affect shipping costs
  • ✓ Material schema so customers can filter the product listing by material
• T-shirt variant
  • ✓ Product schema for basic name, image, etc. (each color variant, at least, will need its own name and image)
  • ✓ Product variant schema to make the different sizes and colors selectable as variants of a parent product
  • ✓ Product SKU schema to track the available stock of a specific variant
  • ? Product price schema to store price if sizes and colors have different prices, or should be possible to separately discount
  • ? Product shipping schema to set shipping info if the different variants will have different shipping costs
  • ✓ Color/pattern schema to represent the color of a specific variant and allow filtering in product listings
  • ✓ Size schema to represent the size of a specific variant and allow filtering in product listings

Let’s examine how these might apply at a more general level, with the terminology from earlier:

• Parent products should implement the Product schema and the Product parent schema, but not the Product variant schema.
• Variants should implement the Product schema and the Product variant schema, but not the Product parent schema.
• Basic products should implement the Product schema but neither the Product parent schema nor the Product variant schema.