sitepoint-editors / TemplatingEngine

A simple, easy to follow PHP templating engine. Designed to be forked, modified, extended and hacked.
MIT License
3 stars 0 forks source link

Too simple? #2

Open zzgab opened 8 years ago

zzgab commented 8 years ago

Hi @AndrewCarterUK, I understand the basic pedagogical point of the tutorial to come based on this library. But in my opinion there is an important part of the template concept that is left aside: this lib illustrates the fact that "PHP is a template engine in itself", as it is often heard from PHP-non-lovers.

I think that one of the main purposes of using templates, is to abstract from the programming language (and possibly let a pure HTML+CSS designer produce the files safely).

What do you think?

AndrewCarterUK commented 8 years ago

Hi @gabrielzerbib -

The debate between going for native templates and ones abstracted from the language is an interesting one. These were the components I was using for inspiration:

http://symfony.com/doc/current/components/templating/introduction.html http://platesphp.com/ https://github.com/PHPixie/Template

I'm assuming you're referring to libraries such as your own, Twig, Blade, etc...

These are essentially two completely different types of templating library. One is for native PHP templates and the other requires its own syntax and markup language. There are benefits to each approach, but you have got me thinking.

What if we could have the best of both worlds?

What if we could have a separate templating component, built on top of this engine, that converted templates from this:

{# parent('app::layout', ['title': 'Blog Post:'.title]) #}

{# block('content') #}
    <article>
        <header>
            <h1>{{ escape(caps(title)) }}</h1>
        </header>
        <main>
            {# foreach(paragraphs as paragraph) #}
                <p>{{ escape(paragraph) }}</p>
            {# endforeach #}
        </main>
    </article>
{# endblock #}

To the form understood by this templating engine:

<?php $this->parent('app::layout', ['title' => 'Blog Post: '.$title]); ?>

<?php $this->block('content', function () { ?>
    <article>
        <header>
            <h1><?=$this->escape($this->caps($title));?></h1>
        </header>
        <main>
            <?php foreach($paragraphs as $paragraph): ?>
                <p>
                    <?=$this->escape($paragraph);?>
                </p>
            <?php endforeach; ?>
        </main>
    </article>
<?php }); ?>

This way:

Thoughts?

Swader commented 8 years ago

:+1: this sound like a novel approach, one we could market as an advantage, and one that indeed does satisfy both camps. The question remains how the conversion happens - is it a manual build process? Automatic on rendering and then cached? Is there a way to "optimize build" as in build once and keep in cache indefinitely, skipping future reparsing?

AndrewCarterUK commented 8 years ago

We could mimic the approach of the opcache. I believe this has levels depending on your performance requirements.

The two methods I'm aware of are requiring a manual cache flush (optimum performance) and performing timestamp checking to see if the file being cached has changed (requires additional hard disk operation).