- v1.0.0-latest-prod
Product Types provide a no-code means of extending the capabilities of the Broadleaf framework allowing Admin users the ability to merchandise different kinds of products - without any developer involvement.
As of Broadleaf 1.4, the concept of ProductTypes was introduced to streamline the process of defining products and preparing them to go live on your site. In the context of the CatalogServices, the primary benefit of ProductTypes is the ability to define type-specific metadata, default values, and validation. This means that you’ll use the same backing Product/JpaProduct domain to manage your products, but can leverage metadata to completely customize the admin form for each ProductType.
The following shows the different ways to filter the Product Browse View by Product Type in the admin, depending on the version and configuration you are using.
Versions before 1.8.4-GA use separate grids (tabs) for each type.
Uses Catalog Service to drive the view.
Versions after 1.8.4-GA use a Selector component instead of separate grids (tabs).
Uses Catalog Service to drive the view.
Note how this includes any Business Types defined in the selector for filtering.
Versions after 2.1.0-GA using Facets to filter
Uses Search Services to drive the view to take advantage of Facets.
Can switch back to the selector with the following property set in your Catalog or Supporting flexpackage.
This will also include any business types as long as a Product using that Type is indexed.
broadleaf:
catalog:
metadata:
faceted-search-enabled: falseA standard product represents a simple sellable good that doesn’t require the customer to select options or variations. A good example of this would be a basketball, or a hot sauce.
Key attributes:
The product has a single, unique SKU for tracking inventory
The product doesn’t have any variations that require the customer to declare a size, color, etc. before purchasing
Variant-based products are different from standard products in that they represent a good that is defined by a set of variants. For example, a shirt is best represented by a variant-based product. In this case, you may have several variants of the shirt such as a small, red variant and a large, blue variant. When the customer purchases one of these items, they must declare which variant they wish to purchase. Simply declaring that they’d like to purchase a shirt would not suffice. Instead, we must know if they wish to purchase the small, red shirt or the large, blue shirt. When rendering the product detail page, the customer can be presented with a list of variants, or they can be given size and color selectors to identify the specific variant that they’d like to purchase.
|
Note
|
ProductOptions should be used to define the attributes (e.g. size and color) that are required to identify specific variants and the possible values of those attributes (e.g. small, medium, and large for the size option). |
Key attributes:
The product itself cannot be purchased. Instead, the product’s variants are the items that can be purchased.
Each variant within the product must have a unique sku, and a "default" variant can be declared for the product by setting the Product.sku field with one of its variant’s skus.
This distinction can be leveraged for things like auto-selecting the variant for the product’s PDP.
Inventory is not tracked for the product. Instead, inventory is tracked for the product’s variants.
Default pricing can be declared on the product, but it is only used if the variant does not declare its own pricing. For example, we could declare on the product that all of the shirt’s variants are $10 by default, but on each of the blue shirt variants, we could declare a $12 price.
As a product merchandiser, you might choose to group a set of items at a slightly lower price to drive additional sales. A bundle product is composed of items that could be sold individually but are grouped and sold as a single unit.
Key attributes:
Pricing is declared for the overall bundle, instead of summing individual components of the bundle.
Discounts can only target the bundle. Discounts targeting individual bundle items are not considered.
To determine if a bundle is available (i.e. if there is available inventory), we must check if all components of the bundle are available. If inventory isn’t available for any of the bundle items, then the entire bundle is considered unavailable for purchase.
Selector products simplify a specific use-case we’ve seen from different clients and prospective clients where a customer is given a choice between several product offers. For example, imagine that you have several different product bundles that you want the customer to be able to choose between. Each bundle could be related but offering a slightly different combination of products. The customer can choose one of these bundles to purchase, with the selector product itself providing general details about the information common to each bundle.
This type of product does not have inventory or a price of its own, but instead allows several products to be displayed and made purchasable on a single landing page. Thus, it is purely a wrapper for related products.
A merchandising product is ideal when you want to create a configurable bundle of various items. For example, you could create a bundle that allows the customer to choose between 3 and 10 items for $5 each. Or you could create a "Buy a shirt from category X and jeans from category Y" type bundle. These are similar to bundle products with two key differences:
The customer is given the opportunity to declare which items to include in the bundle.
The bundle’s price is determined by the sum of the bundle’s items. In other words, each item that is selected by the customer contributes its price to the overall price of the bundle. Note: price overrides can be declared for individual item choices to provide more control over the overall bundle’s price.
Since merchandising products are a means of dynamically bundling other products, they don’t have a SKU value and don’t have any inventory information.
|
Tip
|
Introduced in Catalog Service 2.2.0 |
Broadleaf has enhanced the capabilities of Product Types by allowing management of pre-defined characteristics, which are a set of fields or attributes that are applicable to a certain type of product.
Some general properties of Characteristics include:
Characteristics can be created at a global level and shared across multiple product types - or can be created “inline” and will only be applicable to a specific product type
Characteristics can have values of pre-defined types (e.g. String, HTML, Enumeration, Number, Boolean, Date Time, or Variant Option)
Characteristics can have a default value, so when you don’t specifically define a value on each product offering, implementations can utilize the default value
You can define some configuration attributes about that characteristic, such as its cardinality, whether it’s configurable by the customer, and its uniqueness.
Basic validation settings can be configured
Characteristics can be ordered when assigned to a product type
When you define characteristics on a product type, the Broadleaf admin will automatically build you a dynamic admin maintenance form for that type of product configuration
As an example, for a Product Type that might represent a "Phone", you may have the following characteristics defined
And on the product offering itself, merchandisers will have the ability to manage the actual values for those characteristics.
With characteristics set up on custom product offerings, you are likely going to want to utilize those properties for various capabilities. For example, you may wish to filter, facet, or search on these new properties. You can leverage Broadleaf’s search management capabilities to create an index field for any of these new characteristic values.
As an example, you may have a characteristic called "Memory" on a particular product type. With this, you may want to:
Create a new Search Field called "Characteristic Memory" with the following properties
Type: Product
List of Values: Yes
Abbreviation: characteristicMemory
Field combination: No
property path: characteristics["memory"]?.value
Field Variants: String (Multi)
Include in Results: Yes