Class PageContentBlockUtils

java.lang.Object
io.meeds.social.cms.utils.PageContentBlockUtils

public class PageContentBlockUtils extends Object
Shared helpers telling whether a CMSSetting is still backed by a widget actually present on its page's layout.

This rule has to be applied identically by everything that decides what belongs in the "page" search index: a CMSSetting surviving after its widget was removed from the page doesn't count as a live content block — nothing ever deletes that setting, and the plugin's own content (e.g. the note it names) can very well still resolve just fine, so content availability alone can't tell the two cases apart. Applying the rule in the incremental indexing listener but not in the connector's getAllIds would make every full reindex resurrect exactly the blocks the listener had removed.

  • Field Details

    • WIDGET_SETTING_NAME_PREFERENCE

      public static final String WIDGET_SETTING_NAME_PREFERENCE
      The portlet preference holding a content-block widget's CMSSetting name — must match io.meeds.social.portlet.CMSPortlet.NAME (component/web can't be depended on from here, so the literal is duplicated rather than shared).
      See Also:
  • Method Details

    • collectWidgetSettingNames

      public static Set<String> collectWidgetSettingNames(org.exoplatform.portal.mop.service.LayoutService layoutService, org.exoplatform.portal.config.model.ModelObject root)
      Parameters:
      layoutService - used to load each widget's portlet preferences
      root - the page (or any container within it) to walk
      Returns:
      the CMSSetting names of every widget currently present anywhere in the page's layout tree, read from each widget's own "name" preference.
    • hasWidgetWithSettingName

      public static boolean hasWidgetWithSettingName(org.exoplatform.portal.mop.service.LayoutService layoutService, org.exoplatform.portal.config.model.ModelObject node, String settingName)
      Same rule as collectWidgetSettingNames(org.exoplatform.portal.mop.service.LayoutService, org.exoplatform.portal.config.model.ModelObject), for when only one setting name is in question: stops at the first widget carrying it instead of loading the portlet preferences of every widget on the page.
      Parameters:
      layoutService - used to load each widget's portlet preferences
      node - the page (or any container within it) to walk
      settingName - the CMSSetting name to look for
      Returns:
      whether a widget currently present on the page carries that setting name