Details
-
Type:
New Feature
-
Status:
Open
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: None
-
Fix Version/s: 2.0
-
Component/s: None
-
Labels:None
-
Request Controller:Please Select
-
External Supervisor:Please select
-
Executing Programmer:Please select
Description
Common problem on templated CMS sites is how to provide "slots" for images and several sections of text in a layout, without allowing the content provider to break the layout by inserting images in the wrong place, trying to control text flow etc.
One solution for this might be allowing the definition of "Meta Content" patterns in the respository, using a new MetaContent content type. This parent node would define a reusable (flat) set of content, all nodes that are children of it would make up that graph. This would be much like a Folder but it would have the following differences:
- Requests to render its children would fail (they do not contain real content)
- It would provide a unified editor, with subsections for each child node's title (titles not editable in this unified editor - just headings). Therefore you could edit the content for multiple HTML child nodes and multiple Virtual Content nodes (that e.g. link to image files) in one form. This would be providing default values for that content.
The user would then be able to clone that MetaContent node into another place in the hierarchy, and edit the content (on the one unified screen), so set all the text and resource elements required for the 1 page. The Template used by the MetaContent node would be able to access the content like this:
<div class="main"> <img align="right" src="${wcm.metaContent(part:'mainImage')}"/> <wcm:metaContent part="mainText"/> </div> <div class="sidepanel"> <wcm:metaContent part="panelText"/> <img src="${wcm.metaContent(part:'panelIcon')}"/> </div>
This solution is not perfect yet - possible problems:
- If the original MetaContent templates change, clones of them will not see the change, unless we work some Virtual Content magic that allows you to make local changes to cloned but not-in-your-control child nodes. Seems a bit dodgy
- We may need a new content type for linking to individual files e.g. an image, and a new field editor for selecting a file from the filesystem / image uploader selector
- We'd need to prevent delete/edit of aliasURI of the cloned metacontent child nodes, otherwise it breaks the pattern
- Templates might need to have a field to specify what MetaContent node they expect to work with
- Editing multiple content nodes in the same editor will be problematic if we allow editing of all the Extras/Metadata stuff for each of the children. I think we could just prevent this and only allow editing those on the Metacontent clone parent