Details
-
Bug
-
Status: Closed
-
Top
-
Resolution: Fixed
-
None
-
None
-
None
-
Quasar
-
Puma Sprint 239
Description
Priority top since we rely on this feature with testing XPages:
There is a problem in resolving 'catalog item references'. With the newly support for catalog items, we keep a backreference to an hst:catalog item from a container item. Obviously, a container item needs to resolve these backreferences which happens during model loading.
If it is a non-container-item component, old style component support like inheritance and merging is still needed. The merging can also imply copying of components below for example an hst:abstractpage.
We can for example have the following:
+ hst:abstractpages
+ abstract
+ header (container)
+ banner (containeritem)
+ hst:pages
+ homepage (inherits from /hst:abstractpages/abstract)
+ main (container)
+ foo (containeritem)
in the above example, the homepage should inherit 'abstract/header' which is done in the HST Model by cloning the 'header' component.
HOWEVER, obviously, this only works correctly if the header/banner has already been resolved wrt the catalog item backreference, otherwise a 'non populated' bannner gets copied and after that does not get populated any more. Therefore the loop in HstComponentsConfigurationService
public void populateComponentReferences(final Collection<HstComponentConfiguration> populate, final ClassLoader websiteClassLoader) { for (HstComponentConfiguration child : populate) { if (isNotEmpty(child.getComponentDefinition())) { ((HstComponentConfigurationService) child).populateCatalogItemReference(availableContainerItems); } else { //Legacy component instances support. If component instance does not have a component definition reference, //explicitly populate component parameters. //TODO SS: In case of legacy component instances, there is an extra memory overhead because // field group information & parameter definitions are stored on a component instance level, // instead of storing that on a catalog item level. // More over, field group info has no use during delivery and really belongs to a catalog item level // ((HstComponentConfigurationService) child).populateAnnotationComponentParameters(websiteClassLoader); ((HstComponentConfigurationService) child).populateFieldGroups(websiteClassLoader); ((HstComponentConfigurationService) child).populateComponentReferences(canonicalComponentConfigurations); } } }
needs to be split to first populate component catalog references:
public void populateComponentReferences(final Collection<HstComponentConfiguration> populate, final ClassLoader websiteClassLoader) { for (HstComponentConfiguration child : populate) { if (isNotEmpty(child.getComponentDefinition())) { ((HstComponentConfigurationService) child).populateCatalogItemReference(availableContainerItems); } } for (HstComponentConfiguration child : populate) { if (isEmpty(child.getComponentDefinition())) { //In case the component is a container item, this is legacy component instances support. // If component instance does not have a component definition reference, explicitly populate component parameters. //TODO SS: In case of legacy component instances, there is an extra memory overhead because // field group information & parameter definitions are stored on a component instance level, // instead of storing that on a catalog item level. // More over, field group info has no use during delivery and really belongs to a catalog item level // ((HstComponentConfigurationService) child).populateAnnotationComponentParameters(websiteClassLoader); ((HstComponentConfigurationService) child).populateFieldGroups(websiteClassLoader); ((HstComponentConfigurationService) child).populateComponentReferences(canonicalComponentConfigurations); } } }