Message-ID: <672075038.5.1711719188067.JavaMail.tomcat8@139-162-214-5> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_4_1969470739.1711719187872" ------=_Part_4_1969470739.1711719187872 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
No matter how careful the system is designed to store data initially eve= ntually there will be a time when extra pieces of information will need to = be saved. Data enrichment is part of a natural system life cycle. The platf= orm uses Object-Attribute-Value (OAV) model= that allows to add unlimited number of additional data properties to exten= sible objects at runtime without any coding.
Typical example would be: a marketing team wishes to capture new custome= r preferences for contacting them by telephone. For this a new attribute de= finition would be created in CUSTOMER group. Then the code of this attribut= e definition will be added to registration form attributes configuration an= d profile attributes configuration for a given shop. As a result registrati= on and profile management pages are updated with no coding, no deployment, = it is ready to use as soon as the configurations are applied and marketing = team can use the new customer preference to make more sales.
The platform identifies a number of extensible objects whose attributes = serve various purposes. These objects are identified by attribute group. A = rough depiction of how attributes are grouped and used can be seen in diagr= am below.
OAV mechanism works especially well when applied to product data modelli= ng. Different product types can be modelled to have various attributes whic= h can be shared or be unique to specific products. The mechanism is very ge= neric and is fully controlled from Admin app providing generic no-coding re= quired approach to business functions such as filtered navigation, search, = product specification view and product comparison. For detailed discussion = of the topic see Product information management (PIM).
Attribute groups specify attributes that belong to specific extensible o= bject in the system. This grouping is done for better management of attribu= tes that belong to different functional parts of the system. Out of the box= the platform provides the following groups:
Attribute Group | Purpose | Where to configure |
---|---|---|
SYSTEM | extends the platform itself to contain arb= itrary parameters | System > Preferences section of the admin app= |
SHOP | extends specific shop instance usually to = provide default configurations and adjust behaviour of business functions&n= bsp; | Attributes/Images tab of the shop editor = td> |
CATEGORY | extends master catalog categories and cont= ent objects in the system | Attributes/Images tab of the category/cont= ent editor |
CUSTOMER | extends customer profile information to en= hance quality of data about the customer | Attributes/Images tab of the customer edit= or, for registration and profile forms configuration see this cookbook |
BRAND | extends brand data | Attributes/Images tab of the brand editor<= /td> |
PRODUCT | extends product and SKU information to pro= vide attributes that can be used by product type definitions to create prod= uct specifications and facilitate filtered navigation | Attributes/Images tab of the product/SKU e= ditor |
ADDRESS | defines address capture forms | Configured in the attribute definitions&nb= sp;see this cookbook |
CONTACTFORM = SaaS |
defines contact forms (e.g. contact us, ne= wsletter sign up) | Configured in the attribute definitions&nb= sp;see this cookbook |
WIDGET | define widgets available to select on dash= board, system managed and are used to provide information about the widgets= | Configured in the attribute definitions&nb= sp; |
&= nbsp;
Configuring attributes is a simple task and usually involves creating an= attribute definition in System > Attributes = section. Basic details required are declaration of a unique attribute code = and type of the value for this attribute. After an attribute is created its= code cannot be changed.
Usually attributes are created for a specific purpose such as additional= attributes already supported by the platform, new attributes for custom im= plementations and meta data. When and how the attribute is created and used= will largely depend on the business requirements.
In most cases business users will only need to create PRODUCT attributes= to configure product types. For example product typ= e of "Notebook" may need attributes such as "RAM", "HDD specification" and = "CPU speed", where as product of type "Dress" would need attributes such as= "color", "size" and "collection".
The best way to think about attributes is as a description of properties= of an object. For example when defining "color" attribute for PRODUCT we m= ay specify it as a String property because it is just a colour name but tha= t can be translated into various languages, so it has to be localisable. Bu= t we always search for specific colour so every value that we save e.g. "re= d", "white" and so on will be a specific match in terms of search. On the o= ther had if we are talking about "RAM" we may specify this as a number (e.g= . number of GB), which would allow us to search for notebooks that have RAM= of more than 4GB but less than 8GB and so on. For advanced attributes we c= an even specify validation expression. For example when configuring "email"= attribute for CUSTOMER we can set a regular expression rule to tell the sy= stem which emails are valid and thus prevent customers from entering bogus = emails. There are many use cases and the platform provides a flexible = mechanism to cover this.
Specifying attribute type will also enable some of the features in Admin= app. Thus for specific value types a dedicated editor will be used. For ex= ample String would use a localisable component to capture the value, Intege= r will use a single input with validation for whole number values and Image= will have an upload button and a preview for existing value.
Attribute code should only contain latin letters,&= nbsp;numbers and underscore&nbs= p;characters. It is advisable to set code as a meaningful name (e.g. CART_M= AX_ITEM_SIZE rather than ATTR0001). This will make management of the system= easier in the long run (e.g. when it comes to import).
The following product types are supported by the platform:
Type | Data type | Admin editor | Example | Default validation |
---|---|---|---|---|
String | java.lang.String | Localizable string | any random string | = |
SecureString | java.lang.String | Localizable string + masking in table view= | any random string | = |
URI | java.lang.String | Text input | file://path/to/file | = |
URL | java.lang.String | Text input | http://mydomain/path/to/file.html= span> | = |
Image | java.lang.String | Image upload + preview | image.png = span> Uploaded images will be converted using PNG or JPG encoder only&= nbsp; |
*.png, *.jpg, *.jpeg |
File | java.lang.String | upload + preview | documentation.pdf | = |
SystemFile | java.lang.String | upload + preview | documentation.pdf | = |
CommaSeparatedList | java.lang.String | Text area | Value1,Value2,Value3 | = |
Phone | java.lang.String | Text input | +3(096)5555555 555-55-55 |
^[\+]?[\(\)0-9\- ]+$ &n= bsp;
|
java.lang.String | Text input | bob.doe@domedomain.com |
^[_a-z0-9-]+(\.[_a-z0-9-]+)*@[a-z0-= 9-]+(\.[a-z0-9-]+)*(\.[a-z]{2,4})$
|
|
HTML | java.lang.String | Text area | <div>piece of <b>html</b>= ;</div> | = |
Float | java.lang.Float | Text input | 10.2 -10.2 10 |
^(([\-][0-9]+)|([0-9]*))[\.]?[0-9]+= $
|
Integer | java.lang.Integer | Text input | 10 -10 |
^[\-]?[0-9]+$
|
Boolean | java.lang.Boolean | Checkbox | true false  = ; either true or false<= /strong> |
(true|false) |
Date | java.time.LocalDate | Text input | 2014-04-29 = span> For example 1st February 2010 would be 2010-02-01= strong>. |
^[0-9]{4}\-([0][1-9]|[1][0-2])\-([0][1-9]= |[1-2][0-9]|[3][0-1])?$ |
DateTime | java.time.LocalDateTime | Text input | 2014-04-29 14:42:55 For example 1st February 2010 1:45pm would be |
^[0-9]{4}\-([0][1-9]|[1][0-2])\-([0][1-9]= |[1-2][0-9]|[3][0-1]) ( ([0][0-9]|[1][0-9]|[2][0-3]):[0-5][0-9]:[0-5][0-9])= ?$ |
Timestamp | java.time.Instant | Text input | 1462372975000 = Unix timestamp |
^[\-]?[0-9]+$ |
Locked | java.lang.String | read only | = |
Validation regular expression and message allow to give hints to Admin a= pp editors so that more advanced validation can be performed as opposed def= ault ones for given type.
Customer facing attributes e.g. CUSTOMER attributes that participate in = registration/profile forms or ADDRESS attributes that participate in addres= s capture forms will use the validation expression on storefront and corres= ponding error message will be displayed to customers.
Option | Purpose |
---|---|
Store value in index | Saves value in search index as is. This ma= kes the index larger in size but enables to use this value in CMS on catego= ry browsing and search pages |
Value is searchable | Analyses the value and enables searching v= ia search box by this value using normal, partial and fuzzy searches |
Values is primary key (exact matches) = ; | Strict version of "searchable" which force= s exact matches only (e.g. useful for SKU or model numbers) |
Value is navigatable | Instructs the system to create a facet ind=
ex for this value and enable auto generation of filter navigation blocks |