Jump to content

PHPTAL


Adam

Recommended Posts

I think it is a good alternative. It is one of those rare template engines which at least try do to something interesting with the template language, not "reinvent" a small and limiting subset of PHP.

 

In contrast with Smarty it presents a learning curve as the markup is somewhat complex to understand and follow.

 

I don't agree. Smarty syntax is a limited subset of PHP and esoteric mess with lots of parts broken because they didn't know how to do it better. Contrary to it, TAL language follows well-known XML-rules, and all the functional parts are just XML attributes. Furthermore, it can validate your HTML template syntax which is not possible with Smarty and PHP.

 

Don't listen this stuff about "learning curve". Pure PHP is worthless for templating, and this is why framework developers put tones of complex template helpers to it. Don't they need to be learned, too? Especially, if part of them uses massive object-oriented programming techniques and the same things in different helpers are incompatible one with another? Don't also forget that the learning curve can benefit you in the future - you need some time to learn new techniques, but it can turn out that using them is faster, simpler and cheaper than writing the same thing in pure PHP. Of course it depends on a template language. I think that if you need to do some simple pages, PHP with helpers will be all right. If you have complex needs, or simply want to deal with a different template language, try the modern approaches that offer you more than "just a limited subset of PHP", like Smarty, Dwoo, and 90% of template engines do.

Link to comment
Share on other sites

Thanks Zyx, just the refreshing kind of answer I was looking for. I have to disagree with you ProjectFear that PHP is cleaner, at least from the designer's point of view. Consider the following (admittedly overly simple) example which will just output an array of data - say a list of names - in a table:

 

<?php foreach ($names as $name) { ?>
    <tr>
        <td><?php echo $name['last']; ?></td>
        <td><?php echo $name['first']; ?></td>
    </tr>
<?php } ?>

 

Of course that may look straight forward to you, but then again you know PHP. However, from the designer's point of view remember, take a look at the TAL alternative:

 

<tr tal:repeat="names name">
    <td tal:content="name/last"></td>
    <td tal:content="name/first"></td>
</tr>

 

Much simpler in my opinion. For the sake of argument we'll also include the SMARTY version:

 

{foreach from=$names item="name"}
    <tr>
        <td>{$name.last}</td>
        <td>{$name.first}</td>
    </tr>
{/foreach}

 

Even the SMARTY version looks more complex than the TAL version.

 

Of course you can argue that's a very basic example, but then again if it gets more complex with TAL it's without a doubt going to be more complex within the PHP/SMARTY anyway.

Link to comment
Share on other sites

There is a learning curve with any of those 3 options. If you're going to use smarty, you may as well use just your standard PHP. And I find with templating it's easier to use the alternate syntax with PHP. Even with TAL, there is a learning curve.

 

<?php foreach($names as $name): ?>
<tr>
   <td><?php echo $name['last']; ?></td>
   <td><?php echo $name['first']; ?></td>
</tr>
<?php endforeach; ?>

 

Just my opinion, I think if the designer is going to learn something like TAL or Smarty, why not just learn the same things in PHP?

Link to comment
Share on other sites

Yes but they're designers

 

In most cases it are PHP (junior) developers who convert PSD documents to HTML/CSS not the designers. Ask a designer for the DOCTYPE and he'll answer you ".html". A (junior) developer knows PHP, SQL and possibly HTML, CSS, and JS as these are part of the basic skill set. Only few also know DTD and XSLT hence why I said there's a learning curve.

Link to comment
Share on other sites

MrAdams -> I didn't say that PHPTAL syntax is somehow worse than PHP one. I agree that it is much cleaner than pure PHP.

 

ProjectFear -> for example because well-designed template engines don't do "just a foreach", but can hide many implementation details, optimize it much better (they do not need to worry about the readability of the output code). Consider a nested foreach - in PHP it's you who must built a relationship between them from scratch and you must know, how such a relationship is represented in the template input. If there is a change in a script that requires rewriting it, you end up with lots of templates to fix. On the other hand, the template language can hide everything and you just select a requested way before the template compilation. Something changes - you change one line. You are starting another project? Copy your templates and change the configuration.

 

This is a real situation I encountered. I was using Doctrine and pure PHP templates. After a while it turned out that I don't need to hydrate the data to objects in three or four places, and I can use faster arrays. There was just one problem: I have already implemented three or four quite complex templates (and a bit problematic to read) that worked on these objects and I had to rewrite all the calls to arrays. This is why I think that having two template languages to choose: PHP and some XML-based that can deal with such issues automatically, I would always choose it, not PHP.

Link to comment
Share on other sites

It shouldn't require any more changing then what you would need if you were using TAL or Smarty. Creating templates without Smarty or TAL is exactly the same as if you were doing it with Smarty or TAL, it's just faster because you don't need to it to parse and execute into PHP. It all depends on how you implement it as to how much editing would be required if you change something, and that falls back on to how well it was coded.

Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.