In our application we have a multitude of ValueListProviders with many dependencies. The ValueListProviders are defined in the site project but they are used in the CMS project.
Some dependencies of the ValueListProviders (notably on PageComposerContextService) are broken by version 13 of Hippo because the relevant libraries are no longer included in the site project, and they cannot be added back without breaking other basic things that happen deep inside Hippo libraries.
Moving all of our ValueListProviders from the site project to a common library would be one possible solution to this problem, but this would mean a major refactoring of our code base (relocating several hundreds of source files). If possible we want to avoid this course of action.
I have created a small example application that demonstrates the exact nature of the problem:
Does anybody know of a solution to this, other than moving all ValueListProviders and their dependencies out of the site project?
Hai Jasper,
thank you for your reply. I tried your suggestion but unfortunately this results in an implementation of the mount interface that does not have any site or channel info (neither in Hippo 13 nor in Hippo 12). This is probably the reason that we used the PageComposer to get this information in version 12.
In retrospect, my real question appears to be: how, in Hippo 13, can I obtain the values of channel specific properties while executing code inside of a ValueListProvider method?
An update to let you know we (Dennis Nijssen and I) have managed to solve the problem at hand. I have updated my little proof of concept project.
In order to read the channel settings while executing CMS code, we extracted some code from PageComposerContextService and put it in a custom utilities class. Note that there is some hard coded classname stuff in there that will break once again when Bloomreach decides to further refactor their code base.
This only solved half of the problem.
As it turns out, the ValueList class used in version 12 to obtain the goods (org.onehippo.forge.selection.hst.contentbean.ValueList) still exists in version 13 and lives in a library that is included out of the box in CMS when you follow the instructions for converting from 12 to 13.
However, in version 13 you need to use the other ValueList class
(org.onehippo.forge.selection.frontend.model.ValueList, you need to add a dependency to hippo-plugin-selections-addon-repository to CMS) and completely rewrite the implementation of your ValueListProvider interface to use this other ValueList class.
This little nugget of missing information had me chasing dead ends for quite a while.
Fortunately once I found out that the other ValueList class exists, figuring out how to get such a ValueList by path (and locale) was easy peasy thanks to the existence of the ValueListService class which does all the heavy lifting, and rewriting the implementation of the interface was not difficult (the interface doesn’t use either of the ValueList classes in its definition).
I have update my little proof-of-concept project “gray” (see original post) to demonstrate how it works both in version 12 and in version 13 (check out master branch for 12.6.0, demo-hippo-13 branch for 13.3.0).