Why models are generated in platform extensions?

Hybris is build over the concepts of extensions. Each extension has it’s own data model. Any extension can use an item type from other extension and extend it as per requirement.

For example, the itemtype  product defined in core extension. The catalog extension has extended the product itemtype, and added vendor to it.

While building the hybris, the frameworks builds according to dependencies. Since core is build before catalog extension, it is not aware of the vendor attribute defined in catalog extension. If we keep model class in extensions, then there will e chance of build failures. Like in our case, vendor attribute will not find a place in ProductModel class.


Hybris build framework, creates model classes, even before, building any extension. The platform is the best place to keep them, as every extension is built upon it only. So it is not logical to create model classes in particular extensions, when we can define same data model in various extensions.

What are Catalog aware item types?

While creating a data model for your project, you might come across situations, where you might want some of your item types to be part of catalog. This means, you want them to synchronize, you want them to be associated with a catalog, content or product. Such item types are known as catalog aware. It’s not just CMS item types or products, that needs synchronization. All OOB CMS items and products are catalog aware.

To explicitly make an item type to be catalog aware, follow below steps:

  • Mark your item as catalog item type, using custom property catalogItemType.
  • Choose attribute from item, which will qualify the  catalog associated using custom property catalogVersionAttributeQualifier.
  • Since each item in a catalog must be unique, we need to choose an attribute from item which is unique. This can be done using custom property uniqueKeyAttributeQualifier.

<itemtype code=”MyItemType” autocreate=”false” generate=”false”>


            <property name=”catalogItemType”><value>java.lang.Boolean.TRUE</value></property>

            <property name=”catalogVersionAttributeQualifier”><value>”catalogVersion”</value></property>

            <property name=”uniqueKeyAttributeQualifier”><value>”code”</value></property>



            <attribute qualifier=”catalogVersion” type=”CatalogVersion”>

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

                <persistence type=”property”/>


Once updating your item type, you should update your platform, using system update.

And you should see something like below in HMC > System > item types > MyItemType > Extended


Now, instances of this itemtype will be catalog aware, and would be part of synchronization.

What does partOf modifier means?

In my school, IT department had 5 professors, who taught different subjects of  computer science. School used to manage departments, and professor used to teach. They had their own work life cycles. Everything was so good. But then, school decided to close the department. The professors were bound to loose their jobs. Since they were part of the department. That’s how life is.

When your object is bound to loose it’s existence, when the parent object cease to exist, we say that, child object must have an partOf modifier attached.

For example, An address object is useless, until it is bound to some User object.

Have you heard of cascade-delete in SQL. It describe the same phenomenon.



            <attribute autocreate="true" qualifier="addresses" type="AddressCollection">

               <modifiers read="true" write="true" search="false" optional="true" partof="true"/>

               <persistence type="jalo"/>


Why we have converters and populators in hybris?

I can convert my models to DTO directly in facade layer. Then why should i have a converter?

Its Simple. We may need to convert a product (model) from multiple places. We convert it on product listing page, product detail page, order confirmation page etc. Hybris follows oops concept..So it is good to have a separate class to do this conversion for us, from all of these places.

Converters creates an object of DTO. While populators breaks the code for filling up data in DTO. This is required because, not each DTO needs all attributes of a model. Thus by having multiple populators, we can write more efficient code. Reverse populators are used to fill data in model from DTOs.


The image shows two paths followed (a and b) by two different facades using same converter and different poplators.

We should always use spring injected converters and  populators.

Addon or Extension?

When it come to choose between addon or extension, it becomes a tricky situation. Because we don’t know actually, which one is preferable over another.

Extensions are basically a collection of related functionality, like we have promotion or a store front. It is a larger artefact, in terms of complexity and purpose it solves.

On the other hand, add ons, as their name suggests, are introduced to garnish a existing functionality. They are like toppings over your meal (extensions). For example, a Captcha addon.

  • When we need a functionality, which is used across multiple store front, like captcha, we can go for a addon. We need not to write a separate extension for that. But we can not go for an addon, if we need multiple sites, for multiple country or language. In that case, we need to create separate extension for that.
  • Suppose, you are working with a legacy system, where you can not modify the code base, but you want to modify the look and feel of it’s store front, in that case we can go for a add on.

How to modify attributes of an item type without system update/initialization?

Often we come across the situation, when it is difficult to run a system update, like in production. But still we need to apply some modification at an attribute level.

Hybris has provided Hybirs management console (HMC) , as a graphical tool, which mirrors database in a user friendly way.

Go to HMC > system > type > Search for your item type > Properties.

Here you can apply all sort of modifications you want to do. You can set default values, initial values, mandatory nature etc.




Why hybris deprecated tenant scope?

To understand, the meaning of tenant scope, see my previous post on scopes in hybris. With version 5.0 , hybris decided to deprecate tenant scope.

In verion 5, Hybris has tenant specific application contexts. So the bean you will get will be singleton by default, which is already limited to a tenant. So there is no need to have a different scope called tenant.




As you can see fro above picture, each tenant creates its own set of application context, so now tenant scope is redundant.

Source : Hybris Wiki