A first stab at a better templating system for Chisimba The Chisimba Canvas

Canvas.Id / Canvas.Type = static | dynamic Canvas.Content Canvas.Content.Head Canvas.Content.Head.Header Canvas.Content.Head.Breadcrumbs Canvas.Content.Head.Navigation Canvas.Content.Body Canvas.Content.Footer Canvas.Content.Body.Region2 Canvas.Content.Body.Region1 Canvas.Content.Body.Region3 A canvas can be dynamic (allows turn editing on) or static. A canvas has an ID, which links it to a user, context, or other determining factor.

Canvas.Content.Body.Region2 Canvas.Content.Body.Region1 Canvas.Content.Body.Region3 Wide block Narrow block

Getting the master canvas Currently, the page template does a lot of rendering This would become the responsibility of the master canvas The page template would render the master canvas, with the layout template rendering all the inner layers of the canvas. The page template would contain everything as current up to and including the tag and including and after the tag. $objMasterCanvas = $this->getObject(“mastercanvas”); $objMasterCanvas->renderCanvas(); The rest of the canvas would be rendered by the layout and body templates.

The Layout Template The layout template is static HTML, except for the content, and controls (as was originally intended) the layout. Page templates only setup the properties of the template for rendering. Most of the actual rendering is done in helper classes, not natively in the template as is mostly the case at present. Backward compatibility will be preserved.

For a static canvas, the layout template might look something like the code below: objCanvas->renderId();?>"> Note that the DIVs will be rendered using the appropriate class, they will not be hand coded as in this example. Note that if statements would have to be used to determine if a given layer is to be rendered or not.

Page templates Page templates will typically only set the values of the content elements that will be rendered There should be almost no logic in a page template.  Logic should be in methods of one or more View classes How would we make it backward compatible?

The canvas The canvas would contain all the turn editing on/off logic, and all the logic needed to save the canvas state for a particular rendering of the canvas Turn editing on / off would be available to all modules via a config setting in register.conf. Modules would not output blocks directly, but would create blocks that could be rendered anywhere, and included via default settings. Modules could turn manual block manipulation off by a config parameter.