Custom Addon from Standard Addon: assistedservicestorefront
1. Introduction
Suppose you are working in a Hybris project and your client wants the ASM module to show some customized stuff (as showing in the main header ASM bar a different information, like the total vouchers available in the store). The first thought that comes to mind is that one should create a new extension and overwrite the desire behavior from standard assistedservicestorefront. However, we will show here that this is not the best approach and the workaround is easier that you might think.
2. The cons for extending the assistedservicestorefront
First of all, assistedservicestorefront is an addon. I.e. it is not supposed to be extended by design. The nature of a addon extension is that it should not be extended at all because of:
- one main feature of a addon is to have controllers and they aren’t designed to be extended
- if you want to edit .jsp and other frontend related files it will need a lot of effort in configuration. Sometimes, it will look like it is impossible.
Despite the reasons above, I tried to extend the assistedservicestorefront in a standard way, i.e., creating a new extension and extending the classes I wanted. Well, the result is one advice: don’t do that. That’s silly.
3. Converting assistedservicestorefront into a template
Any extension can be a template. However, the side effects are not predictable.
The ant build framework and the standard Hybris extgen target (ant extgen command in platform) search for some tokens to be replaced inside the files and in the files names, inside the template extension. The problem is that if the extension is not prepared to be a template from the beginning, it can be tricky to get it up and running without conflicts. There are some standard template extensions that were made like this within Hybris. For example, the yempty template, the ywebservices and the yoccaddon.
A possible conflict is having duplicated -items.xml definition. You will need to remove it from the file manually, because Hybris ant targets do not provide support for that much intelligence (because it varies from extension to extension).
However, any extension can be a template and you can create one on your own. As we are trying to customize some features from assistedservicestorefront, we have to transform it to be a template. That’s very simple!
All we have to do is change its bin/ext-addon/assistedservicestorefront/extensioninfo.xml to contain a simple information that it is a template:
1 | <meta key="extgen-template-extension" value="true"> |
This is enough to tell Hybris that this extension may be treated as a template and can be suggested as one when running ant extgen command.
1 2 3 4 5 6 7 8 9 10 11 12 | user@pc:~hybris/bin/platform$ ant extgen Trying to override old definition of task generate_wro_addons_xml extgen: [input] [input] Please choose a template for generation. [input] Press [Enter] to use the default value (ycmssmartedit, yacceleratorstorefront, yacceleratorfulfilmentprocess, yacceleratorordermanagement, ysmarteditmodule, yscala, yacceleratormarketplaceintegration, ywebservices, ygroovy, yatddtests, ycommercewebservices, yacceleratorfractusfulfilmentprocess, ycommercewebservicestest, ycockpit, ybackoffice, ychinaacceleratorstorefront, assistedservicestorefront, yaddon, yoccaddon, yhacext, [yempty], ycommercewebserviceshmc) |
There, you can notice that the assistedservicestorefront is available for choosing as a template. However, if you just continue with the process, and error will be raised and you won’t be able to continue. That’s because there are two very important files missing:
- project.properties.template
- extgen.properties
Both of these files need to be created in order to the ant extgen fulfills its purpose.
The first file will serve as a template for creating the project.properties file for the new extension that will be created. The second one tells ant which tokens shall be overwritten all over the template for creating the new extension.
Again, the second one tells ant which tokens shall be overwritten all over the template for creating the new extension. This is VERY IMPORTANT. If you don’t build this file properly, the information you provide when running the ant extgen command shall be useless, and the extension will have a lot of conflicts. That happens because the code is copied from the template extension to the new one, and if you have the same package names and classes, the ant build framework shall encounter 2 files with the same package and name (same class, in the end) and that won’t work. If you uninstall the template extension and its references throughout the project, the conflicts may happen to disappear. But that is not that good. The problem is: what if you have two different storefronts, one using the standard assistedservicestorefront and the other using a custom assistedservicestorefront? The answer is: you will need them to be all separated from each other. Therefore, you will need the packages to be different in your custom addon than the ones found in the standard extension. And you need to create them inside the Hybris standard extension folder (in this case: bin/ext-addon/assistedservicestorefront/).
And what about these files? What shall we have inside of them?
For the first one, you should only copy the project.properties file from the assistedservicestorefront to the project.properties.template.
1 | cp project.properties project.properties.template |
That should do the trick for project.properties.template file. This because the ant extgen target will overwrite the proper strings and will generate a new project.properties for your extension.
For the extgen.properties file, the contents of it should be (in the assistedservicestorefront context):
1 2 3 4 | YEXTNAME_TOKEN=assistedservicestorefront YPACKAGE_TOKEN=de.hybris.platform.assistedservicestorefront YMANAGER_TOKEN=AssistedservicestorefrontManager YCLASSPREFIX_TOKEN=Assistedservicestorefront |
This file will tell the extgen target to overwrite any folders that match the de.hybris.platform.assistedservicestorefront structure to match the new package root definition the user informs right after running the ant extgen command. It will also redo the file associations throughout the new extension, changing imports in java files and so one, even rewrite .jsp files and tags references. Also, it will replace the assistedservicestorefront string with the name of the new extension when suitable, so Hybris will evaluate the new extension as a total different one.
3. Final Thoughts
That’s all for generating a custom extension from assistedservicestorefront. When running the ant extgen command, make sure to inform the right values to what is required. For example, one could provide the following information:
- assistedservicestorefront – for the extension template
- customassistedservicestorefront – for the extension name
- com.gregoreki.asm.storefront – for package name of the extension
This would generate a customassistedservicestorefront extension, decoupled from the standard assistedservicestorefront, with same classes names but in different packages (no conflicts) and same -items.xml and -spring.xml configuration files. Thus, one need to edit these .xml files to make sure they won’t conflict with any other type.