Proposal Treat Content Blocks like Pages

The basic idea is to allow individual blocks to be represented as pages with the CMS. This would more closely resemble the mental model that users will expect. For example, when they add ‘a new Event’ they immediately want to see the ‘Event page’. Under the current CMS architecture, this would involve creating a Page and adding a portlet to look up the event by id. This proposal would simplify the workflow associated with this process.

UI for editing

There could be two ways to edit individual blocks/pages under this model.

1. Traditional ‘Form’ view – This is how you currently edit blocks
2. Direct Page editing – Both the output and editablity of fields of a block would be defined in the template, and users could directly click on those areas of the page to edit them. This would be similar to how containers work, but would handle editing only one field at time.

Each content type would have a default page layout for it, potentially with ‘preselected’ blocks to make adding a new ‘Event’ page require less work.

Details

1. Each block would have the common attributes of pages, like URLs, cachablity, and templates, etc.
2. Blocks would be addressable, and would be place-able in any section.
3. Portlets can still query for blocks, generate a list, but would have ‘built in’ URLs to link to.
4. No developer would ever need to build another ‘View Block’ portlet.
5. Navigation menus could iterate over blocks in a section. This would make navigation to ‘product catalogs’ easy to do without custom programming, because we could use render_menu.

Mental Model Organization

Focus on semantic types (Homepage, Subpage) rather than mechanical types (Page, Section). Templates could be a primary selection rather than a second thought. Users may think of ‘subpages’ or ‘events’ rather than just a page with a subpage template.

Comments

Buzzware says: "A lot of thought would have to be put in to integrate this into the bcms core without confusing the existing workflow. Some ideas :

1. a custom controller could automagically wrap textblocks in a template and render them under a given url root, including the text block name. Not sure how to associate textblocks with this controller.
2. In the admin GUI, a new kind of site map section node “Block Section” could be created that has an attached standard page, with an empty content marker. Block Section would then contain a visible heirarchy of text blocks, that live at urls combining the section url with their names, and they are rendered inside the Block Section’s page. Block Section would also have the name of the content marker to fill as an editable property.
   "