Re: [PHP Template] My template consideration

At 10:18 PM 2/19/00 -0200, Manuel Lemos wrote:
>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.

It'd be helpful if you could make list of the spotted inconveniences.

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

Do you have any more info about your meta-programming engine posted online
somewhere?

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

I would disagree with this and so would at least our designer. Sometimes
the designer is best empowered by a few well thought out constructs that
she can use without going back to the programmer each time something needs
to be added to the template parsing.

If you have suggestions on how to make syntax less cryptic, please don't
hesitate to make them known.

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

You're talking about an idealized world where designer just plugs content
chunks here and there. What if designer decides that she wants to put a
horizontal rule after each search result, unless there is only one search
result in which case there should be no horizontal rule? Or how would you
handle this situation where you need to output one of the following:

   There has been 1 match.

or

   There have been 2 matches.

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

That's why the proposed template engine will let you have different delimiters.

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

Generation of e-mail is, of course, one of the purposes for the template. I
confess I didn't think about escaping variables with MIME quoted-printable
encoding; I'll have to think on how to handle that.

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

tmpl_*() would only be used by programmers, not designers, but I suppose it
wouldn't hurt to name functions template_*(), except it leads to long ones
like template_get_assigned_vars().


-Andrei