Re: [Fwd: PHPTAL - PHP Template Attribute Language]

> Except...it has some really useful features... > - register prefilter (could you add a 'filter chain to phptal') I use > this to get round problems with frontpage / dreamweaver rewriting paths > in library items. Also for running templates through HTML tidy for > adding missing alt attributes etc. Sounds like a good idea, i put it in my todo, will be done before the end of this week. > - Template resources can come from filesystem, database, ftp etc using > a uri syntax file://path/to/file.tpl.html db://fileid etc > > If we could add these to phptal it would great. > What do you mean ? do you refer to template sources or to data used in templates ? Concerning data retrieval, we can call php functions inside templates : <span tal:define="mydata php:get_data('db://fileid')" /> Concerning template source retrieval, the system is actually based on the file system and your idea is quite interesting. I think about 'SourceResolver' and 'SourceLocator' interfaces, something like : PHPTAL_SourceResolver --------------------- /** * Resolve a template source path. * * This method is invoked each time a template source has to be * located. * * This method must returns a PHPTAL_SourceLocator object which * 'point' to the template source and is able to retrieve it. * * If the resolver does not handle this kind of path, it must return * 'false' so PHPTAL will ask other resolvers. * * @param string $path -- path to resolve * * @param string $repository -- templates repository if specified on * on template creation or with the * PHPTAL_REPOSITORY define. * * @param string $callerPath -- caller realpath when a template look * for an external template or macro, * this should be usefull for relative urls * * @return PHPTAL_SourceLocator | false */ function resolve($path, $repository=false, $callerPath=false) PHPTAL_SourceLocator -------------------- /** * Return source last modified date in a filemtime format. * * The result is compared to php intermediate mtime to decide * weither or not to re-parse the template source. * * @return int */ function lastModified() /** * Returns an absolute path to this resource. * * The result of this method is used to generate some unique * md5 value which represent the template php function name * and the intermediate php file name. * * @return string */ function realPath() /** * Return the template source. * * This method is invoqued if the template has to be parsed. * * @return string */ function data() Would something like this match your request ? *** example : class OwnDBResolver extends PHPTAL_SourceResolver { function resolve($path, $repository=false, $caller=false) { if (substr($path, 0, 3) != 'db:') return false; // ... // - retrieve data from database // - make a source locator around it // - may store the locator so futher calls won't // involve new queries // ... return new OwnDBLocator($res, $path); } } class OwnDBLocator extends PHPTAL_SourceLocator { var $_source; var $_mdate; var $_path; function OwnDBLocator($res, $path) { $this->_source = $res['data']; $this->_mdate = $res['mdate']; $this->_path = $path; } // // retrieve last source modification to compare // with php intermediate code // function lastModified() { return $this->_mdate; } // // retrieve unique source path (mustn't conflict with other // locators) // function realPath() { return $this->_path; } // // retrieve template source // function data() { return $this->_data; } } // create new Template object $tpl = new PHPTAL('db://x'); // add some resolvers $tpl->addSourceResolver(new OwnDBResolver()); $tpl->addsourceResolver(new SomeUrlResolver()); // // 'fileExists' should be replaced by 'isValid' or 'sourceExists'. // if (!$tpl->fileExists()) { echo "unable to locate db://x"; } else { echo $tpl->execute(); } Of course, the template will handle a default filesystem resolver/locator. Any call to metal:use-macro, phptal:include, phptal:src-include, will use resolvers to find template source. Let me know if anyone has a cleaner/better idea, i haven't coded it yet and i'm open to any proposal. > <p>User : > <span tal:content="user/emailAddress | default">Anonymous</span> > </p> The 'default' keyword is in my todo list, should be ok before the end of this week. > I don't think it's in the TAL specs, but another useful addition would > be a 'with' attribute to temporarily change context. So that you could > then use macros for displaying similar data from different objects eg... > > /path/to/macros.tpl.html > <table metal:define-macro="simpleList"> > <tr tal:repeat="item results"> > <td>${item/title}</td> > <td>${item/lastModifiedDate}</td> > </tr> > </table> > > /path/to/display.tpl.html > <div tal:with="articles" metal:use-macro="macros.tpl.html/simpleList" > /> > <div tal:with="books" metal:use-macro="macros.tpl.html/simpleList" /> > That is not in specification and there is an easy way to do it in templates. I also think that too many attributes kills template designers head :) so i go slowly when adding new ones. The 'tal:with' is interesting but when a macro requires more than one parameter, you would prefer a 'tal:param' much like XSLT. Anyway if many users ask me for a tal:param attribute, i'll code one, until that, and since all features haven't been tested yet, i prefer sticking to TAL/METAL specifications. Current way without tal:with : <span tal:define="result articles" /> <div metal:use-macro="macros.tpl.html/simpleList" /> <span tal:define="result books" /> <div metal:use-macro="macros.tpl.html/simpleList" /> Other cleaner way as use-macro content is evaluated before the macro call : <div metal:use-macro="macros.tpl.html/simpleList"> <tal:define="result articles" /> </div> <div metal:use-macro="macros.tpl.html/simpleList"> <tal:define="result books" /> </div> > If you would like any help with the project let me know. > If i find any other bugs I'll let you know. Thousands thanks for your proposition, i surely need help (mainly tests at this time but may be development in a near future). When the system is proven to be stable, i'll start optimizing : - the code generator : too many temporary variables at this time, - the context object : something like a cache of requested pathes so 'path/to/my/object/function' will be evaluated only once and futher calls would internaly resume to 'ref(object)/function' evaluation. There's also an huge work for documentation, i tryied to explain most of PHPTAL in the Documentation.txt file but there's more and more to say :) laurent ps: thank you for the css2 trick, very usefull too. -- Laurent Bedubourg laurent.bedubourg@free.fr PHPTAL :: version 0.4.1 -- testers wanted PHPTAL home : http://laurent.bedubourg.free.fr