Preparing for ccHost 5.0

From Creative Commons
Revision as of 16:20, 24 September 2007 by Fourstones (talk | contribs) (New page: In ccHost 5.0 we are abandoning the PHPTAL template engine. We are replacing it with no real template engine. The HTML pages and XML feeds will be rendered using "straight" PHP files. Ear...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

In ccHost 5.0 we are abandoning the PHPTAL template engine. We are replacing it with no real template engine. The HTML pages and XML feeds will be rendered using "straight" PHP files. Early testing shows that removing PHPTAL from our runtime improves both memory and page rendering quite dramatically - half the memory and twice the speed to render each page. PHPTAL was often charging a ccHost over 4MB per page request. The overhead of the new system is approximately 100k.

If you choose, you can continue to use the same subset of the PHPTAL language we've been using for templates during your development and we will provide a tool that will translate the templates to PHP modules suitable for ccHost.

How does affect you?

  1. If you do not have custom PHPTAL XML templates then the transition will happen behind the scenes during the upgrade.
  2. If you have some custom templates that followed the patterns of the templates in the /cctemplates directory then you will be able perform the upgrade after just a few minor tweaks (perhaps none) to your custom templates.
  3. If you have made extensive changes and/or have custom PHP code that takes advantage of PHPTAL's more exotic features then you will probably have to do a line by line check. For example:
  • In PHPTAL you can pass class objects to a template. In the new system you can not, only arrays.
  • The tal:on-error attribute is ignore
  • The 'structure' keyword is ignored (everything is output as HTML/XML anyway)

Change list

In any event the actual number of changes required for a smooth transition will be small, the changes themselves are typically adding or removing a few characters and the benefits will be huge. NOTE: All changes asked are compatible with the way we use PHPTAL in ccHost 4.x, so you can start making these tweaks today and they will not affect your current installation.

  • no '>' allowed in define clause
 <tal:block define="R php: array( 'cart_id' => 1 );" />


 <tal:block define="R php: array_combine( array('cart_id'), array( 1 ) );" />
  • templates should have tal:block outer-most tags, nothing that outputs HTML (e.g.
  • no duplicate metal macros in the same xml template file
  • no parse-able HTML tags within javascript tags

var t = '



    must be re-written:
       var t = '<' + 'div>hello<' + '/div>';
  • variables won't expand properly in script attributes, move them to script blocks
   <select onchange="cc_get_obj('${home-url}');" >
   re-written as:
      function do_change(obj) {
   <select onchange="do_change(this);" >
  • simple '$' variable won't expand properly in normal attributes, use ${} format
   <a href="$home-url" 
   <a href="${home-url}"
  • get rid of redundant tal: prefixes on attributes (should have been done anyway)
   <tal:block tal:repeat="r records"
   should be
   <tal:block repeat="r records"
  • repeat/* syntax will not work across macro calls. This scenario won't work anymore:
   <metal:block define-macro="foo">
         <tal:block repeat="r records">
                <metal:block use-macro="bar" />
   <metal:block define-macro="bar">
         <tal:block condition="repeat/r/last">
               last one!
   But there is a simple work around, pass the condition as a define:
   <metal:block define-macro="foo">
         <tal:block repeat="r records">
                <tal:block define="is_last repeat/r/last" />
                <metal:block use-macro="bar" />
   <metal:block define-macro="bar">
         <tal:block condition="is_last">
               last one!
  • General note: 'php:' works better than 'string:'. What was:
      <tal:block define="foo string: ${bar} ${baz}" />
   Seems to be happier when it's
      <tal:block define="foo php: ${bar} . '  ' . ${baz}" />
   Another example:
      <tal:block define="K string:tags$repeat/R/key$repeat/C/key" />
   The above will not compile without some help like below:
      <tal:block define="K php: 'tags' . ${repeat/R/key} . ${repeat/C/key}" />
  • How to do variable array indexing. This was crazy to try in the first place but here it was:
    <tal:block define="thiskey repeat/item/key" />
    <tal:block define="avalue  some_array/$thiskey" />
  Note the '$' in the second line. The only way I could keep this functionality and come up with syntax that would work in bothPHPTAL and the new system was to create a helper function in PHP. So the second line above is replaced with:
    <tal:block define="avalue  php: cc_get_value( ${some_array}, ${thiskey}) />
  NOTE: If you make this change you need to put the following code into a module with a .php extension into your local_files/lib directory
   if( !function_exists("cc_get_value") ) {
     function cc_get_value($arr,$key) {
          return is_array($arr) && array_key_exists($key,$arr) ? $arr[$key] : null;
    } }

  • Qualify macro source files when calling macros by name. PHPTAL has a more sophisticated lookup algorithm so:
    <metal:block use-macro="some_macro" />
   would "do the right thing" and look in the current XML file. The new runtime needs more help.
    <metal:block use-macro="some_file.xml/some_macro" />