Details
-
Bug
-
Status: Closed
-
Normal
-
Resolution: Fixed
-
None
-
None
-
None
-
Pulsar
-
Pulsar 241 - Site Dev APIs 1
Description
There are some scenarios that justify allowing overriding java parameters of a ParamsInfo interface (also termed 'named' parameters) with JCR parameters. To properly override, the jcr param needs to have the same name as the param in paramsinfo, and must be of the same type.
A high level scenario that requires this feature is:
I wanna have a news list catalog item available to my webmasters in CM.
On PaaS, the newslist essentials component can be used which extends from the essentials query component. It overrides the paramsinfo to hard-code a default value for parameter "documentTypes". All java based.
On SaaS, I expected we will do the same with a residual (jcr) parameter. Via the catalog REST API, we will create a new catalog item that: # uses the query dynamic component class
- defines a same-name ("documentTypes") parameter as residual, with a hard-coded, project-specific default value, to make sure only news documents are queried for
- (additionally, to showcase this even better) also supplies a hard-coded value for the pickerTypes attribute and pickerInitialLocation
- (additionally, to showcase this even better) defines the value 'true' for the attribute 'hideInChannelManager' of this param, to make sure editors don't change to a different document type
- defines a new label for the catalog item, so it reads "News List" in CM
Currently, jcr params don't override parameters from paramsinfo java interfaces.