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 TemplateJinnTM 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.
|