Skip to content

Dynamic blocks loader

Anton Sudak requested to merge a.sudak/play-cms:dynamic-blocks-loader into master

This merge request introduces Guice based loader for blocks. It provides a way to read enabled/disabled blocks from config file. New configuration keys were introduced:

cms.blocks.enabled
cms.blocks.disabled

both of them are lists of fully quialified block class references. These keys are treated in the similar to the play.modules.enabled/disabled - on application start they would be read and register blocks available for current configuration.

By default following blocks are enabled:

cms.blocks.enabled = [
  "ch.insign.cms.models.PageBlock",
  "ch.insign.cms.models.ContentBlock",
  "ch.insign.cms.models.CollectionBlock",
  "ch.insign.cms.blocks.linkblock.LinkBlock",
  "ch.insign.cms.blocks.backendlinkblock.BackendLinkBlock",
  "ch.insign.cms.blocks.groupingblock.GroupingBlock",
  "ch.insign.cms.blocks.sliderblock.SliderCollectionBlock",
  "ch.insign.cms.blocks.searchresultblock.SearchResultBlock",
  "ch.insign.cms.blocks.jotformpageblock.JotFormPageBlock",
  "ch.insign.cms.blocks.errorblock.ErrorPage"
]

This change provides following benefits:

  • Blocks are pluggable now. We can move every block into it's own package and enable them by simply declaring them as a project dependency. This especially useful for the complex blocks like a ReviewBlock or JotForms. Pluggability would be achieved by putting reference.conf with the one line cms.blocks.enabled += my.cool.block.CoolBlock
  • One less reason to override CmsApiLifecycle. Reducing number of overriding should make play-cms code more open for changes since we would be require to maintain less public interfaces.
  • play-cms got more ways to be configured without writing a code. This would make it more production-ready out of the box.

This is a breaking change. To migrate existing code blocks, following steps should be executed:

  1. all block classes referenced in CMSApiLifecycle#registerCmsBlocks should be moved to cms.blocks.enabled
  2. if any of enabled by default blocks should be disabled they should be added into a cms.blocks.disabled
  3. CMSApiLifecycle#registerCmsBlocks should be removed Alternatively you can keep registerCmsBlocks in your class and call it directly from your class constrictor

In case if block should be registered dynamically during lifecycle of application BlockManager still providers register method, that left unchanged.

If this approach pass the review it could be also applied for registering widgets, filters and uncached partials. With this we'll be able to get rid from overriding CMSApiLifecycle class in every project.

Edited by Anton Sudak

Merge request reports