My template consideration

Hello,

I arrived to this list almost in the begining but it has been hard to keep
up with traffic of 200+ messages. So I had to skip most of them.

Anyway, I think I should make a few consideration so this template engine
won't have to be redesigned later for unsuspected inconviniences that I
have already spotted.

First, a little introduction about my background.  Last year I have
developed a meta-programming engine.  Before you ask, meta-programming
is technique that uses an higher level language to generate intermediate
source code of one or more programming languages.

Other known meta-programming engines are lex/yacc that take some rules to
generate lexers and parsers in different languages, or TeX that takes a
document programming language to generate documents in many format
(document languages).

Back to what matters here, my meta-programming engine is modular.  All
commands are defined by pluggable modules.  There are no built-in commands.
One of the modules is precisely a template engine.

One important aspect of this template engine is that instead of generating
data output, it clips data data blocks of the template source file that
are eventually streamed by the meta-programming engine output that may be
for instance template data mixed with PHP commands if the target language
is PHP, or could C commands that output template data mixed with other
commands if the target language is C.  Other target languages may be used,
but these examples are sufficient for want I want to explain.

The PHP template engine being discussed here is not exactly a
meta-programming engine like I developed, but there are some resemblances
in the way it works.  From the experience I gathered developing my
meta-programming engine and the template module, I realized that there a
few aspects in the PHP template engine being designed that have a few
inconviniences:

- Templates are good because they allow total separation of the visual
  presentantion from the content.  Ideally visual designers produce the
  presentation and programmers develop the content management code.
  Usually programmers are not good designers and designers are not good
  programmers.

  Template design are part of the designers job.  So templates should be
  thought for designers, not for programmers.  What I mean with this is
  that the syntax rules for templates should not be as cryptic for
  designers as it is now.

  As a matter of fact, I think templates should not require any programming
  logic to be useful.  If it contains any programming there you are back
  again mixing presentation with content.

  Separating presentation from content is an important goal because it has
  direct impact on the maintainability of the projects.  A designer should
  be able to change the templates without affecting the content and a
  programmer should be able to manage the content without affecting its
  presentation.

- Templates are basically data with some insertion spot commands.  Defining
  insertion spots in a visual page editor is easy for the designer because
  he just has to type insertion marks wherever he thinks it is suitable.
  However insertion marks may not have characters that will be eventually
  escaped by the editor when saved like < and >.

  Another important detail is that a good template engine could well be
  used to generate other forms of output besides HTML.  Another obvious
  form of output that I am think is personalized e-mail messages like news
  letters.  If MIME quoted-printable encoding is used to generate the
  message body, the set of characters that will be escaped will be a
  different one from HTML.

  To solve this problem, in the template module of my meta-programming
  engine I allow the insertion marks to be redefined.  So a designer can
  use easy to remember inserion marks like for instance:
  ---NAVIGATION-BAR--- .

There are certainly other things but these are for now more important.

Other than this I would like to recommend the use of more readable name
so that people that are not used to this don't wonder what it is all about
or don't find things by obvious names like the infamous unlink function that
a lot of people could not find because they were looking for names like
delete or remove.

So, instead of names like tmpl, I suggest something more obvious like
template.

Regards,
Manuel Lemos

Web Programming Components using PHP Classes.
Look at: http://phpclasses.UpperDesign.com/[email protected]
--
E-mail: [email protected]
URL: http://www.mlemos.e-na.net/
PGP key: http://www.mlemos.e-na.net/ManuelLemos.pgp
--