What are component type group in Hybris?

Not everything is for everyone. This simple law of nature binds everything together. A polar beer is best kept away tropical area. Your business may want to keep only coordinated banners in rotating image banners. The content slots are bounded to have only few type of components to achieve these restrictions.

Components are grouped on basis of their types. These groups are termed as ComponentTypeGroup. There is one to many relations between this group and the components. They are persisted in database. In earlier versions, the valid component list was used just as macro in impex.

This approach is more optimal than the previous one which had a slow many to many relationship between ContentSlotName and Cms Component type.

<relation code="ComponentTypeGroups2ComponentType" generate="true" localized="false" autocreate="true">
			<deployment table="CompTypeGrp2CompType" typecode="1097" />
			<sourceElement qualifier="componentTypeGroups" type="ComponentTypeGroup" cardinality="many" collectiontype="set"/>
			<targetElement qualifier="cmsComponentTypes" type="CMSComponentType" cardinality="many" collectiontype="set"/>
</relation>

There are few groups which are defined in OOB Hybris. We can also define our custom groups.



INSERT_UPDATE ComponentTypeGroup;code[unique=true]
;logo
;headerlinks
;searchbox
;minicart
;wide
;narrow
;footer
;navigation
;mobile

Each valid component type is added to the group.

INSERT_UPDATE ComponentTypeGroups2ComponentType;source(code)[unique=true];target(code)[unique=true]
;narrow;ProductFeatureComponent
;narrow;CategoryFeatureComponent

When a component type is checked against its validity for a given content slot, the system checks if it is contained in the component type group.

INSERT_UPDATE ContentSlotName;name[unique=true];template(uid,$contentCV)[unique=true][default='LandingPage4Template'];validComponentTypes(code);compTypeGroup(code)

;SiteLogo;;;logo
;HeaderLinks;;;headerlinks
;SearchBox;;;searchbox
;MiniCart;;;minicart
;NavigationBar;;;navigation
;Section1;;;wide
;Section2A;;;narrow
;Section2B;;;narrow
;Section2C;;;wide
;Section3;;;wide
;Section4;;;narrow
;Section5;;;wide
;Footer;;;footer
;TopHeaderSlot;;;wide
;BottomHeaderSlot;;;wide
;PlaceholderContentSlot;;;

Why order is important in items.xml?

We need to follow an order in items.xml, when we declare item types in items.xml. Below are the reasons for it.

  • Each items.xml is parsed in single pass. This means, more specific types are dependent on general types. In such case they should have been defined before we use them. For example,

items

Here we see that, item type product is using other item types, like catalog. To make this file successfully, it is mandatory that catalog exist before product is declared. We must defines types in order of inheritance.

Please note that impex files are parsed in multiple pass, so order is not important there.

  • Each xml file is validated against a items.xsd during build. If the xml file does not conforms to xsd file, build will fail.

Data model of Hybris

The hybris data model is made up of type systems.

A type system is defined as a collection of different itemtypes declared in items.xml. Each item type is consist of a Java class which gives access to different members through getter methods and set the values in them through setter methods. In addition to that, each item type has a database entity (table) associated with it.

Item type = Table + Java class

Like any other data model defining entity, item types gives us the flexibility of defining various data structures including primitive one. An data model may consist of integers, Strings or an complex data structure, with a mixture of everything.

For example, let’s take the example of a Student table, having name and roll number.

Student
Roll number Name
123 Ram
456 Shyam

The above data structure of Student can be simply defined as a Java class called Student and two member variable roll number and name.

Student

The above class will give us utility method to access Student object. This class also defines the data types of its member variables. The same is also necessary to define, while creating the database table Student.

So essentially, we can say that a java class and a database entity is something very basic, to create a world, where a java program interacts with a database entity.

Hybris data model collaborated these two and made us write a single xml file declaratively. This gives us freedom from writing create statements in database and also keeps us free from writing monotonous pojo classes.

In real world, the data structures are not as simple, as depicted in above example, rather they are very complex involving floats, double, integers, Strings, collections, enums and nested objects to name a few.

Hybris data model also support each one of them, and we can define every possible data structure in our items.xml.

Atomic types: The item types which are primitive in java, are called atomic itemtypes. For example, integer, float, double, boolean, Strings etc. They are defined in items.xml as follows.

<atomictype class=“java.lang.String” extends=“java.lang.Object” autocreate=“true” generate=“false”/>

Collection type: They are analogue of generic types in Java. A collection is a group of similiar type item types. Like a group of language used for a particular application could be stored as LanguageList.

<collectiontype code=”LanguageSet” elementtype=”Language” autocreate=”true” generate=”true” type=”set”/>

 

 

Enum types: The group of fixed constants are defined as enums, like any other language.

<enumtype code=“ExportStatus” autocreate=“true” generate=“true”>

<value code=“NOTEXPORTED”/>

<value code=“EXPORTED”/>

</enumtype>

To define a general data structure, like that of Student from above example, we need to define a new item type.

<itemtype code=“Student” extends=“GenericItem”

autocreate=“true” generate=“true”                                      jaloclass=“com.blog.hybrisdiary.core.jalo.Student”>

<attributes>

<attribute qualifier=“name” type=“localized:java.lang.String”>                                                                                                            <modifiers/>

<persistence type=“property”/>

</attribute>

</attributes>

</itemtype>

Here we defined an new item type extending Generic item, which is parent of all item type. This item type has only one attribute, name.

The jalo class, is the class which creates the item Student. This class is auto generated.

Each of the characteristics of an item type is defined as attribute of item type. The attibute itself could be of any type, i.e an atomic type like here (String) or another item type.

Suppose, we have to handle student’s address as well. Now it is not advisable to keep addresses as simple Strings. Since address itself, may consist of house number, street number, town, city, country, and mobile number etc. So we should have a separate entity managing the addresses.

<itemtype code=“Address” extends=“GenericItem”

autocreate=“true” generate=“true”

jaloclass=“com.blog.hybrisdiary.core.jalo.Address”>

<attributes>

<attribute qualifier=“town” type=“localized:java.lang.String”

>

<persistence type=“property”/>

</attribute>

<attribute qualifier=“country” type=“Counry”

>

<persistence type=“property”/>

</attribute>

</attributes>

</itemtype>

Here the attribute country of Address is again of type Country. Since Country can have name, isocodes and regions etc. So we used type as Country for qualifier country.

Now we can modify our Student itemtype to accommodate address as well.

<itemtype code=“Student” extends=“GenericItem”

autocreate=“true” generate=“true”                                      jaloclass=“com.blog.hybrisdiary.core.jalo.Student”>

<attributes>

<attribute qualifier=“name” type=“localized:java.lang.String”>                                                                                                            <modifiers/>

<persistence type=“property”/>

</attribute>

<attribute qualifier=“address” type=“Address”>                                                                                                        <modifiers/>

<persistence type=“property”/>

</attribute>

</attributes>

</itemtype>

Items.xml

The data model of hybris is defined declaratively in items.xml. This file is like the nervous system of Hybris project. Every data definition starts from here. This file can be used to define any data structure used in project.

Below are few important points about items.xml

  • The item type in itself, is of type Item.
  • The instance of item type are stored is item type table, but the item type defination is stored in composedType. For example,for the Student item type, the instances of Student will be stored in Student table, but the definition of Student will be stored in composedType table.
  • Any extension can have a items.xml file to define data model used in extension. But this file is not mandatory to have.
  • The order in which the types are declared is very important. The order in which types are defined must conform to below
  • Atomic types
  • collection types
  • enum types
  • map types
  • relation types
  • item types
  • GenericItem is the default parent of each item type.
  • We can extend one item type using keyword

 

      <itemtype code=”ApparelProduct” extends=”Product”>

                          

                           ********

</itemtype>

 

Here ApparalProduct is extending the Product. This is similar to java inheritance concept. The subclass will have all properties of super class. In our case, all the attribute of super class are available for sub class.

  • Ideally we can define an our custom item type, in any extension. But we should define it in relevant extension only.
  • During build of hybris, the extensions are build with taking care of dependency, it makes sure that the parent item type is available.
  • We can control the access to an attribute using modifiers.

<attribute autocreate=“true” qualifier=“code”                     type=“java.lang.String”>

<persistence type=“cmp”             qualifier=“internalCode”/>

<modifiers read=“true” write=“false”   search=“true” initial=“true” optional=“false”            unique=“true”/>

</attribute>

Here the code attribute, is readable, but not writable. It means it’s value cannot be changed, after it is set once.

read – If false, we cannot access it from our java program.

write – If false, we cannot modify the value.

optional– if false, it is mandatory to initialize this attribute. Since it is not optional.

unique– if true, the attribute must hold a unique value. Similar to unique constraints in DBMS.

search – if true, the attribute is searchable through queries.

  • We can control, how the tables are created for an item type. The default table for each item type is genericitem. The table is called as deployment in hybris. So GenericItem is the default deployment.

<deployment table=“UserRights” typecode=“29”/>

Here the table name will be UserRights. The type code is used internally by hybris to generate primary keys. We can give any positive integer for typecode, barring few reserved integers.

  • If we do not give a deployment tag for a item type, the instances of that item type will get start to store in Generic item table. This will cause generic item table to expand drastically, which is a not good for database performance. So we should always give deployment, if our item type is extending generic item directly.
  • Persistence is one of the property of item type attribute. if this property is set to property, it means that attribute will be stored in database. If it is set to dynamic, the attribute will not be part of database table. It is just calculated at run time. This is similar to calculated column in DBMS.

Extensions in Hybris

Hybris suite is a package of number of business functionalities, like a storefront to checkout products, a platform to provide spring features, a service layer to provide persistence and lot others.

Each of these functionality is available as an isolated java project, which has it’s own data model (if required), its own spring configurations ans properties etc. This grouping of similar functionality into one java project is termed as extension. Below is a snapshot for commerceservices extension from hybris.

ext1

An extension may or may not have a web interface. It may depend on other extensions to fulfill it’s purpose. This information is defined in extensioninfo.xml

The data model of extension is defined in <extension-name>-items.xml file.

The spring configuration for an extension is defined in <extension-name>-springs.xml. It has all bean definitions, dependency injections etc.

Each active extension of your hybris project must find a place in localextension.xml

What is an attribute?

While defining the various properties for an item type, we need to define many things about the property itself.

For example, for customer, mobile number is a property. Now mobile number itself could have many properties. Like whether it is mandatory property? How many digits it will have? Is customer is allowed to change the mobile number?

So basically we need a data structure again for the properties. In hybris the properties or characteristics of an item type are known as attributes. The attribute itself could be of primitive type (like string, or integer) or it could be of type like that of any other item type.

It is defined within the definition of item type in items.xml

it corresponds to column of database.

What is an item type?

Be it a desktop or web application. Be it java or any other technology. Be it small or big size application. Any application works on some kind of data. The data here could be real time exact data like customers, products, promotions etc, or meta data (data about data).

We need to define a data structure for any application. These definitions of data structure contains the meta data about real data. For example, if Ram is a customer. Then name, email, mobile number could be Ram’s actual data, but some where we need to define, what properties of Ram (Customer) , we are likely to keep or interested in our application scope.

Such definitions of anything in application is defined as item type in Hybris. Possible examples are Customer, Product, Promotions, vendors, Categories, Stores etc.

In hybris, the item types, are basically the XML declaration of various data structures used. They are defined in items.xml.

The item type is not just about defining data structure. Hybris also generates POJO classes for each defined item type. They are known as model classes. This class provides getter and setter method for attributes. instanceThe above table shows the approximate analog of item type with Java and DBMS sysem.