Skip to content


Subversion checkout URL

You can clone with
Download ZIP


phly_mustache 1.2.2
- [#28](#28) Allows whitespace in
  tags, as long as no whitespace occurs before any sigils.


phly-mustache 1.1.1
- [#28](#28) Allows whitespace in
  tags, as long as no whitespace occurs before any sigils.


phly/mustache 1.2.1
Total issues resolved: **1**

- [25: Heirarchical templates with same parents use the results of the first render returning for subsequent renderings](#25)


Version 1.2.0 - 31 July 2012
- Added Resolver API
  - Resolvers return mustache syntax, or mustache tokens
  - Mustache class now proxies to Resolvers instead of incorporating
    that functionality
  - DefaultResolver allows specifying suffix, path stack additions, and
    directory separator character (allowing "" to resolve to
- Fixes to hierarchical templates
  - Fixes an issue wherein placeholders nested more than one level deep
    did not propagate to all parents.
- Documentation
  - New end-user documentation (thanks to @harikt and
  - API documentation (generated by phpdoc)
  - New website landing page (
- Travis-CI integration


Adds two new features:
 - Dot notation (originally added in mustache.js). Allows using dot notation in
   variable names, which will then dereference nested objects and/or
   multi-dimensional array views. As an example:


   as a template can then be injected with one of the following views:

    $view = array('foo' => array('bar' => 'baz'));

    $view = new stdClass;
    $view->foo = new stdClass;
    $view->foo->bar = 'baz';

   or any combination of nested objects or arrays.

 - Hierarchical templates. This adds two new token types to the grammar, the
   placeholder ("$") and the child view template ("<"). This is best understood
   through an illustration:

    <!-- super.mustache -->
    <head><title>{{$title}}Default title{{/title}}</title></head>
    <div class="content">
    {{$content}}Default content of the page{{/content}}
    <footer>Default footer</footer>

    <!-- sub.mustache -->
    {{$title}}Profile of {{username}}{{/title}}
    Here is {{username}}'s profile page

   Given a view that defines "username" as "Matthew, the following output will
   be generated:

    <head><title>Profile of Matthew</title></head>
    <div class="content">
    Here is Matthew's profile page
    <footer>Default footer</footer>

   Placeholders that are not overridden in the child will receive the default
   value; if the placeholder is overridden in the child, then that value will
   be used. The value may contain mustache tokens, in which case they will be
   rendered using the current view scope.

   Hierarchical views may be arbitrarily nested.


Phly\Mustache is a Mustache ( implementati…
…on written

for PHP 5.3+. It conforms to the principles of mustache, and allows for
extension of the format via pragmas.

Phly\Mustache consists of four primary classes:

- Lexer: tokenizes a template
- Renderer: renders a list of tokens, using substitions provided via a view
- Pragma: interface for pragmas, which may modify how tokens are handled
- Mustache: facade/gateway class. Tokenizes and renders templates, caches
  tokens, provides partial aliasing, and acts as primary interface for

The 1.0.0 version provides:

- The above classes
- An autoloader
- Pragma support, including:
  - IMPLICIT-ITERATOR (iteration of indexed arrays or Traversable objects with
    scalar values, with the option of specifying the iterator "key" to use
    within the template)
  - SUB-VIEWS (allows implementing N-step view patterns)


1.0.0 - Third RC
- Further fixes potential security vectors via callbacks composed in a view
  (reported and fixed by Andy Thompson)


1.0.0 - Second RC
- Fixes a potential security vector (reported by Mark Baker)


At this time, phly_mustache is feature complete.
The following tasks still exist, but should not affect the API:

 - Better handling of whitespace stripping. It works, but still presents some
   odd indentation in isolated instances.
 - Should the full text matched be kept with each token? This really only
   benefits those debugging the lexer and/or renderer.
 - Unit tests for tokenization; these may be dependent on the above items,
   however. Tokenization is implicitly tested via the test suite at this time.
Something went wrong with that request. Please try again.