In some cases, Page templates are used as a repository of macros. A single page
template may contain multiple reusable macros which participate in a global
rendering process. In this case, we should not only follow the same naming
convention as for scripts (CapitalizedWords) but also make sure that such page
templates can be called and tested on a standard object. This means that no page
template should ever be designed in such way that does not make it renderable by
invoking it on an appropriate portal type instance.
The underlying idea is sometimes called prototype programming (cf.
HyperCard). It is similar to the idea of proxy fields in ERP5
Forms. Rather than using abstract macros from isolated page templates, new page
templates should be designed by reusing bits from another working page template.
However, to make the system more maintenable, it is recommended to gather all
macros in a large page template which serves as a kind of example of reusable
UI components. This why the name of such pages should end with Renderer.