Hi there

Just a quick question: Do you have any plans dropping the support for php < 5.3 in future releases? I'm going to write a patch (at least I'll try) which add Namespaces and Interfaces which will break the compatibilty to the current supported versions of php (php 5.1.x?).

I think it would be very handy to able pass closures to PHPTAL variables, or to objects that are themselves passed to PHPTAL, such as:

$tpl->foon = function () { return 'barn'; };

Currently PHPTAL will try to concatenate $ctx->foon, which results in "Object of Closure could not be converted to string."

You can get around this via:

//template
<tal:block content="func:foon"/>
//php
function phptal_tales_func($src, $nothrow) {
    return 'call_user_func(' . phptal_tales($src, $nothrow) . ')';
}

...but I think this is behavior we can actually build into PHPTAL. I will implement myself if I get positive feedback about this.

It's been a while. Shall we make a release?

I wonder if #9 needs to be fixed before next version can be released. Slots in nested macros are a pain. The 1.2.2 version doesn't get it right either, but is buggy in a different way :(

Other than that it's pretty good:

• Support for closures
• default json and urlencode modifiers
• Support for namespaced classes in TALES modifiers
• Improved registering and unregistering of custom TALES modifiers
• Updated list of HTML5 elements/attributes
• Better error messages when keys are missing in arrays
• Improvements to HTML-compressing prefilter
• Consistent checks for truthy values
• Non-UTF-8 encoding support in PHP 5.4
• Throwing in chained expressions
• bunch of other bugfixes

Currently PHPTAL package is released only as dev-master via Packagist. But it does not have stable code and users may be confused by difference of each other in the same release name 'master'.

https://packagist.org/packages/phptal/phptal

I suggest to point a version number tag as 1.2.3 to master brach. Then Packagist can take it as new numbered release package.

I and my friends want to use PHPTAL by Composer but also want to use a stable version of it. (It also includes HTML5 tag fix.)

Installs the lint tool in the composer bin directory.

I wasn't sure whether to rename phptal_lint.php to phptal_lint as other tools don't have the .php extension but I thought it was best to leave it for now in case anyone is using any test tools which expect tools/phptal_lint.php to exist

If you want to have a tag ommited, using the omit-tag directive, but, for example in this tag you want to access the same attribute you are checking to omit the tag, PHPTAL throws an error.

An example could be to display an image in a gallery and add a link to that image. Some images have link some others do not. You could wrap the img tag into an a tag, using tal:omit-tag to check if the $image/link exists. If it does, $image/link could be used to set the href attribute using the tal:attributes tag.

Here the code:

<a tal:omit-tag="not:exists:item/link" tal:attributes="href item/link">
    <img tal:attributes="src item/image" />
</a>

In its current implementation, this throws an error, because PHPTAL checks tal:attributes before it checks tal:omit-tag.

I haven't done much PHPTAL work in recent years, and currently I'm focused on completely different projects.

I still think it's the best templating language for PHP. The code is good and stable.

Is anybody interested in taking over the project?

When using tal with a high amount of different templates and macros (I'm talking about millions of different templates), the code destination folder gets filled up with cache files within no time - especially if you dont want to clear the directory every 10 minutes. This slows down the filesystem access to the specific directory (depends on the environment - filesystemtype, nfs, etc.).

This patch introduces a configurable level of subpaths which are added to the phpCodeDestination to create a structure of max 32 subpaths with 0 as default to avoid impacts on existing installations.

The readme currently makes no mention that PHPTAL can be installed through Composer, also the DEV dependencies mentioned in the README file do not appear in the composer.json file.

Maybe I could patch the readme and composer files to fix this?

• Adds instructions to the README file on how to use PHPTAL with Composer.
• Adds a 'require-dev' section to the composer.json file so the development requirements can be installed through Composer.
• Does minor cleanup for the links in the README file.

closes #14

If you set a boolean attribute on an element using tal:attributes, it will use the value of the variable instead of setting the boolean value. This results in invalid HTML for that attribute.

The boolean attribute list is also incomplete for HTML5, but that is probably a separate issue.

To reproduce, use code/template like this:

$tpl->boolat = true;
<!DOCTYPE html>
<html>
   <head><title>Boolean Not setting</title></head>
   <body>
      <input tal:attributes="disabled boolat" />
   </body>
</html>

When the template is emitted, it will specify disabled="1", and this does not validate at least for HTML5. If you set a boolean attribute without using tal:attributes, it will be set properly.

This code:

$TALTranslator = new \PHPTAL_GetTextTranslator();
$TALTranslator->addDomain('mydomain', './locale');
$TALTranslator->useDomain('mydomain');
$TALTranslator->setLanguage('', 'en_US'); // Empty string as first argument

Will throw this exception:

Language(s) code(s) ", en_US" not supported by your system.

Looks like some sort of strange string concatenation problem as indicated by the leading comma in the list of languages in the error.

in line PHPTAL.php:828 used not atomic writes via file_put_contents if (!file_put_contents($this->getCodePath(), $result)) {

OpCache in some cases is in time to store an empty file into the cache. Potential reasons for it is high RPS, high concurency, slow disks and so on.

File exists, it's not empty, there are no errors while requiring file, but function is not defined and we have this log message: E_ERROR: Call to undefined function tpl_... in: /var/local/www/app/outsource/PHPTAL/PHPTAL.php:667

I recently used the features described in the NEWS section:

PHPTAL 1.3.0 2014-03-16

Added support for closures
Added support for namespaced classes in TALES modifiers
Added default json and urlencode modifiers
...

In particular the urlencode modifiers.

I was looking everywhere how to do it, but I couldn't find them in the documentation, only in the NEWS section. I'm glad they are there, and they work, even inside of escaped variables like so:

 <a tal:attributes="href string:http://www.example.com/${urlencode:myVarWithBadCharacters}">test</a>

which is awesome, but documentation should really be there.

On the releases page it states that there was added support for closures: https://github.com/phptal/PHPTAL/releases

However, I found that when I used a closure directly on a template variable a closure would not work. Only when using a "repeat" tag do closures appear to work. I'm not sure where you would fix this, but I found that closure support was provided in RepeatController.php in these lines:

elseif ($source instanceof Closure) {
    $this->iterator = new ArrayIterator( (array) $source() );

So perhaps something similar needs to be done.

For example this will fail to load: $details = function(){return 'some string';}; $template->details = $details;

<b tal:content="details"></b>

But if $details was a closure that returned an array and it was iterrated over like so it works:

 $details = function(){return [0=>['name'=>'Jim']];};

<li tal:repeat="detail details" class="media">
    <div tal:content="detail/name">Name Here</div>
</li>

There might be a typo somewhere in that code but you should get the idea.

I wanted to use a closure to lazy load my template variable but it only worked when I used repeat, so I believe I found a problem. I found that I can temporarily work around this problem by returning a one element array and using the tal:repeat directive.

Introduction

In the conversation on #48, it became apparent that it might be useful for the PHPTAL website to fall under the same responsibility as the code-base.

Currently the PHPTAL site is hosted on @pornel's personal server.

It might be a good idea to set up a phptal.github.io repo and use Github Pages to host the content of the PHPTAL website.

This issue is for discussing the pro's/con's and details of what such a plan entails.

Details

The website currently consists of the following sections:

• Download
• FAQ
• Introduction / Homepage
• Mailinglist
• Manuals
• News
• RSS/Atom News Feed
• Wiki

As far as I can tell all of the pages can be served from static content except for the wiki. Github offers wiki functionality, so that might be enough to port the current wiki to.

Github Pages also has support for RSS feeds so that shouldn't cause a problem.

Having all the docs (both the manual and the site) in a repo would allow people to send in PRs and would make it possible to automate things.

If PEAR support is eventually dropped, http://phptal.org/latest.tar.gz would not longer have to be updated. For the time being, this would constitute a commit/PR for each new release. (If that becomes too cumbersome the process could be automated in a build step).