%kb_name - %short_descr - Knowledge Portal

Tech Talk: Intro to Storefront Spec Forms

The Storefront solution introduces the concept of variable products, which are products that have configurable options. These products can be used to drive any number of solutions, e.g., Configure Price Quote, Customizable Variable Documents, and Variable Specs. While the default product functionality is robust and is frequently all that is needed, there are times when creating additional functionality around these forms is necessary. Let’s take a look at that process and touch on some of the capabilities.

AngularJS

AngularJS is the single page application framework used in the reference applications of Storefront. The customizable points within the administrative interface are designed for the AngularJS framework. When you are in Storefront and click into the “Storefront 2.0 tab” within a product template, you are actually altering a “view” that is defined in the Angular routing table. When a user navigates to the product, this custom view will be loaded onto the screen.

Spec Forms

One important point to explore is the AngularJS $scope object. In our case, the $scope variable defines the product, or more specifically, the variant. The variant is the data model of the product and it contains all the specifications, or “specs”, that drive a product’s customizable variations. The specific spec objects belong to the “Variant.Specs” object collection within the app. A custom directive library is used to display these objects for input, which allows for enhanced data input and more robust data input controls. For example, if you wanted the user to have a calendar from which they could select a date, you could use the “customdatefield” directive.

Building Additional Functionality into the Spec Form

Angular revolves around the concept of “two-way binding”. Two-way binding means that any model value bound to the UI will be maintained between the view and the controller. In other words, changes made in the view are reflected in the controller and changes made in the controller are reflected in the view. Using our spec form example, we access the “Value” property of the spec object in order to leverage this two-way binding capability.

function SpecController($scope) {
          $scope.Variant.Specs.Name.Value = “My Name”;
});


<section class="specform-default" ng-controller='SpecController'>

Notice the attribute named ng-controller that has been added to the <section> element. This attribute defines the controller that will be associated with the view. Within this same view we see the SpecController function. Note that the function name matches the ng-controller attribute definition. We inject the $scope object by adding it as a function parameter. Doing so gives us full access to all the objects loaded into the $scope. One of these objects is the “Variant” object, which represents the product we want to customize for ordering.

In the example above, we set the value of the Name spec. This value will then be reflected in the input control in the UI.

It is possible to expose additional capabilities by hooking into events. The most common way of doing this is to react to the change event of a spec value. Here is a simple example of how to accomplish this:

function SpecController($scope) {
          $scope.$watch(‘Variant.Specs.Name.Value’, function(value) {
          if (!value) return; // only respond if the value is set
                               Variant.Specs.Title.Value = value; // example of setting the value of another spec during this change event.
          });
}

The key point of interest in the example above is the $watch function, which the Angular framework exposes on $scope. The $watch function is the data change event, and the function parameter (in this case “value”) is the new value that was changed.

This article is merely an introduction to spec forms. We’ll continue to examine spec forms and the nearly limitless capabilities they offer.