[2009-03-09] Make SSViewer a facade for different rendering engine backends

[silverstripe-issues]

created by: @chillu (ischommer)
created at: 2009-03-09
original ticket: http://open.silverstripe.org/ticket/3686

---

Turn SSViewer into a facade for different backends (similiar to Requirements class).

Template engines should be selectable by "site mode" - as the CMS backend will most likely stay in standard SSViewer syntax, while the frontend templates are exchangeable.

Each template engine would register one or more file extensions (.ss=SSViewer,.tpl=Smarty). This is a necessary convention to avoid confusion in any "autodetection" and fallbacks.

Ideally, templates would fall back to the "default implementation" (SSViewer) - otherwise its hard to use templates from external modules - e.g. a website might render Page.ss in Smarty, but include BlogHolder->TagCloud(), which renders TagCloud.ss via SSViewer.

Some requirements for the facade:

• Pass in context object (mostly a Controller object with fallbacks to the model)
• Set template cache folders
• Passing in of selected theme folder
• Location of template path by filename (manifest)
• Setting of "debug" parameters (?debug_request and ?showtemplate)
• Allow manual "assigning" of template variables in addition to auto-assigning all public properties and methods available in the context object

How about naming this facade View, and keeping SSViewer as a specific renderer implementation? We would need to pass SSViewer::process(), ::current_theme() etc. through to the new View implementation though for legacy reasons, which might be more trouble than its worth...

[sminnee]

Stale enhancement.