Details
-
New Feature
-
Status: Closed
-
Normal
-
Resolution: Fixed
-
None
-
None
-
None
Description
Currently a component's raw parameters are exposed, which includes the personalization rules/annotations. However, it doesn't tell which personalized or testing variant is served. Therefore it would be helpful to expose only the resolved parameters of a component.
Additionally, I don't see a large enough use case to also include the raw parameters next to the resolved parameters. If these need to be included we can always do this later on.
From Ard in ESSCOM-31 (we can leave item 4 out of scope for now):
I think the parameter info object contains very valuable information to have in the serialized result. It does mean that we have some overlap with the 'params' section but I think the the parameter info object can add valuable information pieces:
1) Customers can instead of using the parameter names/values, instead use the logic names in the parameter info object: In general they are the same but not always. For example take a look at org.onehippo.cms7.essentials.components.info.EssentialsCarouselComponentInfo. There we have
@Parameter(name = "document1", required = true) @JcrPath(isRelative = true, pickerInitialPath = BANNERS_INITIAL_PATH, pickerSelectableNodeTypes = {HIPPO_DOCUMENT}, pickerConfiguration = CMS_PICKERS_DOCUMENTS_ONLY) String getCarouselItem1();
The parameter name is "document1", the returned json page model api property would however be 'carouselItem1'
2) The parameters info object is completely in sync with what is shown in the hst component window dialog
3) The big difference with 'parameters' as serialized now, is that the parameters info object has a representation of the targeted parameters only : So instead of showing all parameters in case of targeting, it only shows the targeted parameters. Assume we target on geoip, and we have three banners, one for US visitors, one for EU and a default one. The parameters info object will for #getBanner return the targeted banner. The parameters object as we currently have it will show all the banner parameters (prefixed with some value which cannot be interpreted by the react/angular app, for example the name of the parameter might be something like (I think from the top of my head)
@1521109009$["and",{"continent":"europe-EU"}]banner
where happens to be '\uFFFF'. This is not helpful for the react/spa app.
4) If we use the parameter info object, we can decide to include more info. For example we can tell what kind of parameter it is. Pretty much all information you can for example see at
@JcrPath(isRelative = true, pickerInitialPath = BANNERS_INITIAL_PATH, pickerSelectableNodeTypes = {HIPPO_DOCUMENT}, pickerConfiguration = CMS_PICKERS_DOCUMENTS_ONLY)
Obviously (4) is quite a bit more work and out of scope for 0.9 I'd think.
Finally, personally, as a consumer of our page model api, I'd be more interested in the parameters info object than in the parameters object I think.