How to customize error message in store front

Unexpected conditions is something, which is unavoidable in any application. So is Hybris store front. There may be hundreds of situations, where you would like to show an error message to users. The error could be because of, wrong user input, unavailability of data, inadequate exception handling or some thing else. But the bottom line is, it is unavoidable.

Hybris provides a very flexible and modular approach to show error messages. But your customer may still want to customize the way we show error messages in store front.

GlobalMessages class

While serving a particular request in your java classes (controllers, facades, service, dao etc), whenever you come across a error situation (like validation error or a possible null pointer etc), you should use this class. This class provides static methods to add error messages to your model object.

There are different type of messages, you can add to your model. They include confirmation message, error or warning messages.

global

 

globalMessages.tag

This tag is used to actually render the error message at a particular position and some css. Now you can customize the csss as you want.

error

The error messages, are present in base properties. If you want to add a new type of error message to your store front, you should do that in Global message class.

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”>

        <custom-properties>

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

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

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

        </custom-properties>

        <attributes>

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

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

                <persistence type=”property”/>

            </attribute>

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

1

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.

<attributes>

            ...

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

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

               <persistence type="jalo"/>

            </attribute>

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.

blog1

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.

What are different kind of property files in Hybris.

Hybris provides a flexible way to manage properties for your project. You can configure as many as properties as you want in your project.

  • project. properties : This is actually a extension level property file. The properties defined here are available only for the extension, it belongs to. You should define the properties,  which are to be used only in this extension. Hybris provides a property file for each extension by default. The value for a given property is based on the experience and convenience. For example, the URL for HAC.
  • Local.properties : We have another file called local.properties. This is available per tenant for the overall application. This file is used to define modify the values given in extension specific project.properties file. So it will basically overrides the project.properties file value. For example, we can give, database connectivity parameters in this file.
  • We should always use local.property file to customize the behavior of hybris. As any migration or upgrade will not effect, the values to go to default ones.
  • We also have localization property files, to manage the internationalization of project.
  • We need to restart the server to make an effect of change in any property value. Build is not necessary.
  • We can use the properties even in spring managed beans. We can pass them as a property of a bean.
<bean class="StockService">
  <property name="defaultStocklevel" value="${default.stock.level}"/>
</bean>

Logs are printed twice in console

Hybris comes with bundled Log4J logger. This is used for every logging activity in hybris.

We can define log levels for each extension and even each package. So if we have defined logger level for sub package, then it will execute twice. For eg;

log4j.com.package.name = debug,appconsole

log4j.com.package.name.subpackage = debug,appconsole

So every logging  activity for subpackage will be run twice, once for parent package and one for sub package.

We can disable it via:

log4j.additivity.com.package.name.subpackage=false