Implement product display patterns with KentiCopilot
When our team implemented the product catalog example in the Training guides repository, we needed a way to display the products we had wired and prepared on a website channel - both for a listing of several products and details of a specific product.
Specialized page templates and content-type-based controllers were among the possibilities, but we decided Page Builder widgets would maximize our flexibility. Widgets allow us to display listings or featured product callouts on pages throughout the site. They work with existing page templates and content types, so we don’t need to add a content type for product listing pages or new templates.
Let’s examine some important considerations when creating product display widgets, and how agentic AI coding assistants and the KentiCopilot widget creation plugin can help.
The KentiCopilot widget creation plugin contains two skills: one for researching and creating instructions based on your requirements, and one for implementing widgets based on those instructions.
Before you start
This guide requires the following:
- Familiarity with C#, .NET Core, Dependency injection, and the MVC pattern.
- Understanding of Page Builder, Reusable field schemas, and Taxonomies in Xperience by Kentico.
- A running instance of Xperience by Kentico, preferably 30.11.1 or higher.
Some features covered in the training guides may not work in older versions.
Code samples
You can find a project with completed, working versions of the widgets described in this guide and others in the finished branch of the Training guides repository.
Terminology
Before we start, let’s establish two terms for product types that we will use throughout this material.
Product variants - distinct versions of a given product based on attributes such as size and color, that merit a distinct entity.
For example, if a jacket comes in multiple colors and sizes, a shop would likely track stock for each individual combination, like small black jacket, small gray jacket, medium black jacket, etc.
Parent products - products which have variants. Parent products are often abstract — they hold shared info and represent the relationship between their variants, but cannot be directly purchased or stocked.
For example, a shop might sell multiple quantities of the same canned energy drink with 6-pack box and 24-pack box variants. The variants are tied together by a parent product called Super Energy that contains branding, nutritional information, and a description.
To get a handle on the content model and features of the Training guides product catalog implementation, check out our product catalog overview guide.
Define your widget requirements
Start with your requirements. AI assistants can help to some degree, bringing up common features and questions for consideration. Even so, it’s always a good idea to discuss requirements with stakeholders, such as editors who will use the widgets and the administrators who will manage the e-shop.
Analyze product listing requirements
For a product listing widget, ask how your clients plan to list products across the site.
- Should product listings appear on multiple pages?
- Will there be subsections within the store for different categories of product, each with its own listing?
- Should any pages show listings of products located elsewhere in the tree?
- Will editors need to filter the product listing? If so, how?
- Will live site visitors need to filter the product listing? If so, how?
- Which parts of the listing UI should the widget hide under different circumstances?
- Does the site have exclusive content for signed-in members? If so, how should the listing widget handle secured content for unauthenticated users?
- Will the products have variants? If so, will the listing need to pull up any data from the variants, or is all the pricing, image, and stock information available from the parent product?
Scope product detail requirements
For a product detail widget, ask about the circumstances under which your clients want to display different product info.
- How many data points will each product detail have?
- Should different product types have different view model classes, or can you package information from several content types into one view model?
- If some products have variants, should variant details combine with, display alongside, or replace details from the parent product?
- Which product details should the widget show or hide under different circumstances?
- Will the site advertise featured products by showing a subset of their details outside of the product’s own page?
Format your requirements for KentiCopilot
KentiCopilot’s widget creation tools use the Xperience by Kentico documentation, along with specialized plugins and templates, to generate step-by-step instructions for building a widget from your requirements. Then the tools execute those instructions to create the final widget.
When you draft these requirements, it’s important to include details about the widget, including visual presentation, data retrieval requirements, and error handling.
The KentiCopilot repository includes a widget requirement example that you can use as a template for widget generation.
Consider having an AI agent review your requirements file for AI understandability. It can suggest improvements and prompt you for more information that you might not have thought of.
You can also provide an optional design file with a mockup of the widget’s visual appearance for the agent to replicate in the final code. We did not create such a file in the Training guides example.
Widget requirements in the Training guides
In the Training guides repository, our product catalog used generic Product page items that referenced reusable product items of varied types, each with its own variants.
We wanted the Product listing widget to display the details from product pages below the current page in the tree by default, with the option to select a different tree section. We set requirements for taxonomy-based product filters for live-site visitors, and configurations that let editors decide how to handle secured items for signed-out users.
We wanted the Product widget (product detail) to retrieve product data from the current page by default, with the option to select a different page instead. We also decided it should have a call-to-action link to the selected product that editors can configure or hide.
These are the requirements files we used:
# Product listing widget
## Selection
- The widget allows marketers to choose a section of the content tree and displays a list of all product pages (ProductPage) within that section, including links to the product pages.
- The widget displays product pages from beneath the current product page by default
- The widget includes filters for taxonomy tags in `IColorPatternSchema.ColorPattern` and `IMaterialSchema.MaterialSchemaMaterial`, configurable by the visitor on the live site
## Presentation options
- Secured pages: In cases where a ProductPage or its underlying IProductSchema item is marked as secured, determine whether to filter the product out of the listing or include it with a prompt to sign in
- Call to action text: Determine the text of the CTA link for each product
## Content retrieval
- Use existing methods from `IContentItemRetrieverService` where possible.
- When new retrieval functionality is required, add functionality to `IContentItemRetrieverService` and its implementation `ContentItemRetrieverService` instead of using the APIs directly.
- Retrieve the relevant product data and add it to a `ProductViewModel` using the appropriate methods from `IProductService`.
- Add any necessary missing functionality to the `IProductService` and its implementation `ProductService`
- Include the product page and the product (`IProductSchema`) it links
## Styling
- Use the existing Site.css styles to match the design of other components on the site
## Error handling
- Missing products: If no products are found, display a message that no products meeting the criteria have been found.
## Technical requirements
- Always prefer the *Combined content selector* (ContentItemSelectorComponent) over the *Page selector* (WebPageSelectorComponent).
- Each product in the list should include a title, an image, a call to action, and a stock status
# Product widget
## Selection
- The widget allows marketers to choose between displaying the current product page (default) and choosing a specific product page to display.
- The selector for products should only be available when a marketer chooses to display a specific page, and should be hidden when the widget is configured to display the current page.
## Presentation options
- Call to action: Determine whether or not to display a link to the selected product page
- Call to action text: Determine the text of the CTA link
## Content retrieval
- Use existing methods from `IContentItemRetrieverService` where possible.
- When new retrieval functionality is required, add functionality to `IContentItemRetrieverService` and its implementation `ContentItemRetrieverService` instead of using the APIs directly.
- Retrieve the relevant product data and add it to a `ProductViewModel` using the appropriate methods from `IProductService`.
- Add any necessary missing functionality to the `IProductService` and its implementation `ProductService`
- Include the product page, the product (`IProductSchema`) it links, any variants (`IProductVariantSchema`) linked by the product, and any images or other items referenced by the variants.
## Styling
- Use the existing Site.css styles to match the design of other components on the site
- Ensure the teaser image fills the full width of the widget's container
## Error handling
- Missing products: If selected products are missing from the database, display a message to the marketer only (not visible in live mode)
- Current page is not product: If the widget is set to display the current product page, but the current page is not a product, display a message to the marketer only (not visible in live mode)
## Technical requirements
- Create a widget view model that includes a `ProductViewModel` object.
- Always prefer the *Combined content selector* (ContentItemSelectorComponent) over the *Page selector* (WebPageSelectorComponent).
Context helps
Because we tested other product functionality during development, we already had a shared product view model and a product service before using the widget creation tools. Additionally, our repository already contained other similar widgets, such as an article listing widget that handled secured content in the same way we wanted for this widget.
You may need to provide more detail about things like content retrieval, membership, and the relationships between types in your content model.
Examine your generated widget instructions
The widget-create-research skill analyzes your requirements and uses them to generate highly detailed instructions for creating a widget.
Before running the widget-create-implementation skill, review the generated instructions and correct anything the agent may have misunderstood or omitted during the research step. This ensures your agent has all the information it needs to create the correct widget functionality.
Widget creation instructions in the Training guides
In the case of the Training guides product widgets, we ended up skipping this step. Originally, we intended to go through a quick test run of the widget creation process, to create a proof-of-concept and get new ideas of what to prompt for in the widget requirements. After that, we planned to start from the beginning for a more thorough iteration.
However, the results of the first run were very close to what we needed, and it was easier to tweak the final output than start over. We also thought it might be a good opportunity to test the process under imperfect circumstances.
Refine the output with iteration
After running the widget creation plugin, you may not be totally happy with its output. There are two approaches you can take to iterate on the results of the widget creation tools.
Tweak the results
The KentiCopilot widget creation tools don’t include a plugin for refining widgets after their creation, but agentic assistants can still handle these refinements effectively, thanks to the documentation MCP server and the context of your existing project.
For many changes, such as adding new properties or changing the visual layout of a widget, agents are perfectly capable of adding or modifying widget functionality without dedicated instructions and plugins acting as guardrails. This is especially true when your project has existing widgets, so the agent can analyze your conventions.
Start from scratch
By discarding the files resulting from the widget creation process, you can adjust your input to cover what was missing and start fresh. You can fall back one step, and adjust the widget creation instructions directly, or you can return to the start and adjust the requirements in order to generate better instructions.
This approach works best when something major is off. If you need to significantly redesign the widget’s core functionality, it may be more efficient to restart from the requirements or instructions step and address the issue before the next iteration.
Refinement in the Training guides repo
As mentioned earlier, our first run of the widget creation plugin for product widgets was intended to be a proof of concept, but the results were quite close to our target, so we decided to keep the output and make minor changes. Let’s look at some of the specific tweaks we made, which were quickly implemented thanks to AI coding assistants:
Product listing widget changes
- Add a new view model to wrap the
ProductViewModel, which includes the URL of the product page holding the product and a property to represent whether access is denied for the current visitor. - Adjust the filter to work based on query string values.
- Add view model properties to indicate normal price vs sale price, and visually indicate when a product is on sale.
Product widget changes
- Display thumbnails of all product images, with a small script to click through them.
- Add stock status to the product title, including an icon.
- Visually indicate when a product is on sale.
You may notice that some of these were the result of oversight in our requirements, due to the hasty proof-of-concept nature of our run. They might not have been necessary if we had spent more time refining before using the plugin’s research skill.
See the results
In the end, you should end up with functional widgets for displaying products to your customers.
Here is how the Training guides Product listing widget looks in action:
Here is the Product widget in practice:
You can see the working code for both widgets in the finished branch of the Training guides repository.
What’s next?
The next guide in this series does a deep dive on the filtering functionality in the product listing widget, so you can follow along to create it.
If you haven’t already, check out our product catalog overview guide and implement a handler that keeps ProductPage wrappers in sync with reusable Content hub products.