Re: [PHP Template] My template consideration

Hello Andrei,

On 20-Feb-00 00:15:14, you 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.

I thought I just did that. :-)


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

Unfortunately no.  I have absolutely no time to document it.  Since it is
not publically available it is not a priority for me either.

Anyway, just a small overview, I developed it to solve a set of recorrent
problems in Web development, like maintainability, development time and
associated costs, distributability, etc.. Its development is not part of
any research program, but rather part of the development of a very large
and ambitious project, which is too soon to talk about it, but it is also
irrelevant here.

All I can say for now is that it is fully XML driven.  This means the
meta-source code format is based on custom XML formats but this has nothing to
do with XSL/DOM/SAX/whatever world.  XML is just used because it is
structured enough to make it easy to be parsed and generated by arbitrary
editor programs or human beings.

As I mentioned the language is completely defined by modules.  There are no
built-in commands or modules.  Even programming flow logic and expression
handling is done by individual modules.  This makes the language so
flexible, that you may use different syntaxes with the same
meta-programming engine.

The modules do almost everything you wish including documentation
generation (one source, multiple output formats), build process management
(make files), project files bundling (build RPM, tar, etc..  archives), DBMS
independent database interface, generate forms, reports, etc..  Modules can
do anything you need.

The whole engine is done in PHP which only fault is it's interpreted
nature, so compiling a large project takes a lot of time. This will change
in the future.

As a side note, you'll be hearing a lot meta-things not just from me of
course. Last month Linus announce the meta-CPUs of his company (TransMeta).

There is also other people working in XML based scripting engines
(http://www.xmlscript.org/ which is not quite meta-programming).

Paul Meagher is working on a meta-scripting engine in PHP that is basically
, the way I understood it, script generator wizard
(http://www.metascripting.com/).

My DBMS independent database interface module uses Metabase package which
provides a consistent interface to access databases and there is a XML
based format to define database schemas which may be installed in any of
the supported databases (http://phpclasses.UpperDesign.com/browse.html/package/20).

Anyway, all these meta-programming efforts are meant to accomplish the
goals described above.


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

Maybe I am not expressing myself properly.  What I mean is that only the
designer should be editing templates. If the pages require any programming,
that should not be requires to lay on templates because most designers are
clueless regarding programming constructs.

The way I see it, the role of the designer is to prepare the visual
presentation details, like the imagery and the layout.  Everything that
requires managing programming logic should not be done by the designer even
if he knows a little about programming.

If you put a designer doing a function that he is not best skilled at, you
are looking for several kinds of trouble, like disputes in your team, jobs
get delayed because the programmer more efficiently are done slowly because
the designer has little or no idea how to do them properly and usually ends
up copying and pasting some less than adequate solution borrowed from
somewhere else.

So, why bloat the template engine with programming logic that would fit
best in the base scripts?  Only if the programmer is meant to do everything
and so there will be no disputes.  In that case you won't be separating the
presentation from the content which goes against the initial goal of
templates.


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

Looking to the way how your template engine is expected to work I
understand your questions.

The way I see it should be which is the way it works with the my template
module, is that instead of inserting programming lines within the template
data, it clips template data and merge it in the programming flow.

The way I would solve your example with my template module is to use more
than one template file.  Basically ther is a master template that defines
things like headers and footers.

Then there are individual template files that define things like the layout
of individual entries on listings.  There the designer could put rulers or
whatever he thinks it is best.

The code generated by my template module would just extract the specified
template data clips and merge it in the code, eventually in a loop that
would output it as many times and the programmers code figures.

As for the search result sumaries phrases is one of those things that
absolutely belongs to the programmer domain.  The phrases are dynamic
contents:  they depend on run time variables.  If the designer feels they
should look differently, just define different template clips for each one.
Now, it is by no means to the designer domain to figure the logic as which
they should appear.  Remember:  run-time computed output -> programmer
domain, design time presentation output -> designer domain.

Personally I wouldn't even allow a designer to define texts if I expected
that sooner or later the pages would be served in different languages.  I
have a separate module that manages localization.  There would be a lot
more to say about this.


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

hardcoded entities like $ # % < > ! don't seem to be any meaningful for
non-programmers. What about using letters instead?


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

Sorry, I missed that you can redefine marks in the .ini file.



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

If you can redefine marks in the defaults file, that is no longer a problem.


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

Beginning programmers appreciate names that speak from themselves.  It
won't be these details that will hurt the engine performance.


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