Dynamic blocks loader
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 linecms.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:
- all block classes referenced in
CMSApiLifecycle#registerCmsBlocks
should be moved tocms.blocks.enabled
- if any of enabled by default blocks should be disabled they should be added into a
cms.blocks.disabled
-
CMSApiLifecycle#registerCmsBlocks
should be removed Alternatively you can keepregisterCmsBlocks
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.