The Assortment contentarea

Within the SMV we already defined the assortment contentarea as follows:

Let's model the corresponding CAV by adding one item at a time, starting with the header and the list of products. Until now we haven't defined what aspects of a product should be shown, so let's say that each product of our product list consists of a name, an image, a weight and a price indication as well as a short description.

Since this site is a very low-budget site, we will only list 10 products. We could model this by placing 10 elements for each product aspect in the Assortment CAV, but we can also use a list element instead.

The AssortmentHeader is a simple TextLabel element. So the documentation of it is straight forward:

Documenting the elements within the list elements would require that we add 10 tables for each element within our list element. To be able to express that a certain tables belong to the same product instance we use add a referential path to the element identifier, like Product[5].Name or Product[7].Image (Note that there is a dot between the element identifiers; The dot is chosen to ease the communication with developers who often program using an object oriented programming language).

But since the description for each element within our list remains the same we use a generic indicator (n) to express that the element properties remains the same for each instance.

Finally we have to add the properties of our list itself to our documentation.

We now have a list but we want to be able to select items from the list. By adding a min and max selection our list becomes a SelectList element . Since our customers are not required to order anything we can set the min selection to 0. But our customers may order all of our products, so the max selection will become 10.

Because our List element has become a SelectList element we have to adjust our property table.

Now our customers may only order 1 item of each of our products. So we have to add something to our SelectionList to be able to express an order quantity. We do so by adding a TextInput element together with a corresponding TextLabel element to tell the customer about the purpose of the TextInput element.

Next we will add the remaining elements mentioned within the description of the contentarea.

You might have noticed that the InputText elements of delivery address and e-mail address have a shadow. This is a visual representation of the mandatory property.

To submit the order we need an order button. We represent the button by a simple text label that can trigger a link.

If we take a look at our sitemap than we see that the order link will result in a validation.

In the specification of the Choice Element “validate” we already stated that we need information from the contentarea first in order to determine the decision base property.

Based on the decision description, we see that the decision is based on the contentarea elements txtDeliveryAddress . DeliveryAddress and txtEMailAddress . EmailAddress.

To determine whether or not a product has been ordered, we can either state that any item of the CAE Product has been selected. But determine whether or not there is any QTY item within the SelectList Product that has a value greater than zero might be more specific.

Our new specification of the SMV Choice Element “Valide” therefore becomes:

Finally the validation might generate in an error event resulting in a navigation back to the Productpage. Displaying the page as specified we get the problem that the customer doesn't get any feedback and therefore doesn't know that he didn't pass the validation check.

To solve this problem we could add a popup to the link, we however choose to display the error messages within the assortment contentarea.

The error messages are just normal text labels containing a text that informs the customer about the mistake he made. Including the error message within this contentarea doesn't mean that they are always visible (that is handled by another plugin), but that they semantically belong to the content of the assortment contentarea.

Getting back to this contentarea not only means that an error message should be shown, but also that the values entered previously should be visible again. So we not only have to add the property tables of the error messages, but also have to change the intended content of the text input elements.