You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This would make it easy to hook in third party blocks for individual sites without requiring special integration from the CodeRed project. For example, issue #15 could easily be solved with this enhancement for sites that want it without any additional burden on the codebase.
Since all of the pages are implemented in abstract fashion I think this would be pretty straightforward. Migrations would be handled at the implementation level and shouldn't cause any conflict with CodeRed.
Recently when I encountered the need to add custom blocks, I redefined the lists and then wrote mixins that override the "body" field to apply them to my pages. This is kind of clumsy and my next thought is to monkey patch the lists... but I would prefer to take a different route if possible.
I think this would be generally useful for most implementations. What do you think? Is there another plan in place that I have missed?
The text was updated successfully, but these errors were encountered:
I just found #305. I could be wrong but I think what I am describing is compatible with migrations. It would just require a migration when the value changes which is normal
It is fairly cumbersome to add additional blocks to the pages.
It would be nice if the variables used for holding "types" of blocks was passed through a hook/signal/something that allowed global modification of these lists: HTML_STREAMBLOCKS, CONTENT_STREAMBLOCKS, NAVIGATION_STREAMBLOCKS, BASIC_LAYOUT_STREAMBLOCKS, LAYOUT_STREAMBLOCKS, STREAMFORM_FIELDBLOCKS, STREAMFORM_BLOCKS
This would make it easy to hook in third party blocks for individual sites without requiring special integration from the CodeRed project. For example, issue #15 could easily be solved with this enhancement for sites that want it without any additional burden on the codebase.
Since all of the pages are implemented in abstract fashion I think this would be pretty straightforward. Migrations would be handled at the implementation level and shouldn't cause any conflict with CodeRed.
Recently when I encountered the need to add custom blocks, I redefined the lists and then wrote mixins that override the "body" field to apply them to my pages. This is kind of clumsy and my next thought is to monkey patch the lists... but I would prefer to take a different route if possible.
I think this would be generally useful for most implementations. What do you think? Is there another plan in place that I have missed?
The text was updated successfully, but these errors were encountered: