TemplateJinn

There are many different templating systems on the market. Many try to be everything to everyone. -- including this one. The following summarizes the virtues of the TemplateJinn^TM system.

• Modular compiler framework
• Extendable tag and embed compiler bases
• Powerful multilingualism features
• Infinite template/source nesting
• InterJinn modules and components support
• Database properties support
• Templates compile to PHP content

These are the main advantages; however, it is expected that you will discover many others in contrast to existing templating systems. The following sections further describe the above points. Please feel free at any time to use the links to your left to navigate through the individual sections which constitute the TemplateJinn framework.

Modular compiler framework

The TemplateJinn system supports multiple compilers to be applied sequentially on any content/ This is done automatically by the template manager when you begin compilation. The exact compilation sequence depends on what compilers you have configured. With this system prewritten compilers can easily be added to the list to provide any functionality you need. Alternatively you can write your own compiler that supports anything you can develop.

Extendable tag and embed compiler bases

It is expected that many developers will want to create their own compiler for whatever reason. Tag and embed compilers are the two main types with which developers will usually work. To facilitate easy development of either kind, a base class exists which can be extended to provide the same kind of functionality obtained when using the <jinn:xxxx/> tags and {jinn:yyyy} embeds.

Powerful multilingualism features

There are many Websites that target a diverse audience, often encompassing more than one language. To meet this need the InterJinn framework supports many features to simplify the development of multilingual content. The TemplateJinn framework does this by supporting multilingual context lookup when importing templates, source files, or database properties. This has the effect of properly separating one language from another, while allowing templates to be built in a language neutral fashion. This feature is optional and can be configured.

Infinite template/source nesting

This feature allows the content developer to provide a hierarchical separation of different types of content. Generally speaking there are three types of content that can be imported into the main template. When a template is imported into a template, then that template can itself import other templates, and so on and so forth. The same is true of source files. Furthermore to provide functionality similar to that found when hyperlinking, such templates and source files can be imported relative to the the outer nested template or source file respectively. This has the advantage of making the site structure very flexible and robust.

InterJinn modules and components support

It seems that many templating systems these days have a high degree of logic embedded in the template structure. This undermines the very principle of separation of content from business logic. Since InterJinn is not just a templating system, but an application framework, it circumvents this issue by properly having the user define logic in modules and components. Then content created by such logic can be requested with the appropriate <jinn:module/> or <jinn:render/> tags. This makes maintaining a large site simplistic, and frees the developer from needing to learn some awkward and strange new language described by the templating system -- additionally it places the full power of PHP at the fingertips of the developer.

Database properties support

So you find that you are constantly linking to some sites and you are tired of hard-coding the URL into your anchors. Well the TemplateJinn framework just happens to work with the InterJinn property system. All those URLs you defined for your components can be re-used in your content. This leaves you one solitary place to change the value of the URL if it should change. But wait, using properties can be somewhat wordy, well why not just create a little tag compiler that just requests the name of the URL? With the <jinn:property/> tag, you can choose between having the content of a property included statically or dynamically.

Templates compile to PHP content

This is the last point on the list, but it is hardly the least. In recent time I've seen templating frameworks slammed because PHP is itself a templating system. While this is true, and PHP does provide a fast system for including files, PHP is not overly friendly to content developers, nor is it simple for providing complex templating functionality. More often than not, content developers don't want to use functions, they want to use tags since that's how they use HTML. That said, and obviously TemplateJinn allows tags, there is usually a tradeoff with speed in most templating systems. Because of the overhead of implementing an inclusion system in PHP, the speed often drops for systems that include the content at runtime. TemplateJinn skips past this shortcoming, and even improves over PHP itself, since the content is included at compile time, and subsequently, requests to the web server do not generate runtime includes. Furthermore, every tag with dynamic functionality in TemplateJinn is compiled to pure PHP code in the resultant output file and when template content changes, the target file is recompiled once.