Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Fetching contributors…

Cannot retrieve contributors at this time

148 lines (83 sloc) 7.186 kb


Forking GRMustache

After you have forked groue/GRMustache, you might want to change stuff, test, and then build the library.

You'll find below some useful information on each of those topics.

Change GRMustache

Classes in a glance

The library features are described in the guides. This section describes the classes that implement those features. They are organized in a few big domains:

  • Parsing

    • GRMustacheParser
    • GRMustacheToken

    The parser is able to produce a parse tree of tokens out of a template string.

    For instance, a parser generates three tokens from Hello {{name}}!: two text tokens and a variable token.

  • Compiling

    • GRMustacheCompiler
    • GRMustacheRenderingElement
    • GRMustacheSectionElement
    • GRMustacheTemplate
    • GRMustacheTextElement
    • GRMustacheVariableElement

    The compiler consumes a parse tree of tokens and outputs an abstract syntax tree of rendering elements.

    Rendering elements are actually able to provide the rendering expected by the library user. Templates render full templates and partials, section elements render Mustache sections, text elements render raw text, and variable elements perform variable substitution.

    For instance, from the tokens parsed from Hello {{name}}!, a compiler outputs an AST made of one template containing two text elements and a variable element.

  • Runtime

    • GRMustacheContext
    • GRMustacheHelper
    • GRMustacheInvocation
    • GRMustacheSection
    • GRMustacheTemplateDelegate

    During a template rendering, a context implements a state of the context stack that is initialized with the initial object that the library user provides in order to "fill" the template, extends when entering sections, and shrinks when leaving those.

    A context is able to provide the value for an identifier such as name found in a {{name}} tag.

    However, it is not fully responsible for the value lookup. Invocations are the definitive objects that provide values that should be rendered. For instance, invocations are able to perform a lookup for key paths such as

    Invocations are generated by the compiler. Each variable and section element, also generated by the compiler, owns an invocation that provides the value that should be rendered.

    Those invocations are exposed to the template delegate, so that the library user can inspect or override values that are rendered.

    There is another way for the library user to hook into the template rendering: she can implement helpers in order to have some sections behave as "Mustache lambda sections". In order to be able to perform the job described by the Mustache specification, they are provided with section objects that provide the minimum required information.

  • Template repositories

    • GRMustacheTemplateRepository

    Template repositories are objects that provide templates out of template strings from various sources.

    GRMustache ships with various template repositories that are able to load templates from the file system, and from a dictionary of template strings. The library user can also provide a data source to a template repository, in order to load template strings from unimagined locations.

    Finally, template repositories are responsible for providing the compiler with template partials.

  • Misc

    • GRMustache
    • GRMustacheNSUndefinedKeyExceptionGuard

    GRMustache provides with library configuration.

    GRMustacheNSUndefinedKeyExceptionGuard is a funny tool that allows the library user to avoid his debugger to stop on every NSUndefinedKeyException raised by the template rendering.

Project organisation

Objective-C files that make GRMustache are stored in the src/classes folder. They are added to both GRMustache4-MacOS and GRMustache4-iOS targets of the src/GRMustache.xcodeproj project.

Headers are splitted in two categories:

  • public headers
  • private headers

Public headers

Public headers must contain only declarations for APIs that are exposed to the GRMustache users. They must not import or include any private header.

Methods and functions declared in public headers must be decorated with the macros defined in Classes/GRMustacheAvailabilityMacros.h. Check existing public headers for inspiration.

src/classes/GRMustacheAvailabilityMacros.h is generated by src/bin/buildGRMustacheAvailabilityMacros.

Private headers

Private headers have names ending in _private.h. They must not import or include any public header. The set of public APIs must be duplicated in both public and private headers.

Test GRMustache

Before running the tests, make sure git submodules are downloaded:

$ git submodule update --init

There are two kinds of tests, all stored in the src/tests folder.

  • tests of private APIs
  • tests of public APIs

When a file is added or removed from the src/tests folder, both GRMustache4-MacOSTests and GRMustache4-iOSTests targets of the src/GRMustache.xcodeproj project are updated.

Tests of private APIs

Tests of private internals are stored in the src/tests/Private folder, and are all subclasses of GRMustachePrivateAPITest.

The implementation files of those tests must not include any public header.

Tests of public APIS

Tests of public GRMustache API are versionned: the src/tests/Public/v4.0 folder contains tests for features introduced in the version 4.0 of the library. src/tests/Public/v4.1 contains tests for the version 4.1, etc.

Those tests are all subclasses of GRMustachePublicAPITest. Their implementation files must not include any private header.

You will use the macros defined in Classes/GRMustacheAvailabilityMacros.h. They help the tests acheiving three goals:

  • use only APIs that are available in the GRMustache version they test against,
  • emit deprecation warning when they use deprecated GRMustache APIs,
  • help GRMustache achieve full backward compatibility.

For instance, all header files for public API tests in src/tests/Public/v4.1 would begin with:

#import "GRMustachePublicAPITest.h"

When you add a test for a public API, make sure you place it in the folder that introduced the API (check the release notes), and NOT in the version that will include the new code. For instance, if version 4.6 introduces a fix for an API that was introduced in version 4.2, the version 4.6 will then ship with new tests in the src/tests/Public/v4.2 folder.


Building GRMustache is building the /lib and /include folders, which contain public headers and static libraries for iOS and MacOS.

In order to build them: make sure git submodules are downloaded first:

$ git submodule update --init

Then, issue the following command:

$ make clean && make


Jump to Line
Something went wrong with that request. Please try again.