Rendering a template with section referencing a string in the context results in a condition. For each char of the string render is called, which leads to an exception:

(mustache:mustache-render-to-string "{{#author}}{{author}}{{/author}}" '((:author . "what"))

There is no applicable method for the generic function:
  #<STANDARD-GENERIC-FUNCTION MUSTACHE::DATA #x302001C28E6F>
when called with arguments:
  (#\q)

The actual output should have been:

"what"

This i case is not covered by the mustache specs but it seems to be an alternative to the dotted names syntax. (See also https://gist.github.com/zickzackv/8247170)

The git documentation says "The different Mustache tags are documented at mustache(5)." but the link is dead. Would it be possible to put this file into the tree?

Tests fail on the cl-mustache version included into the recent alpha release of Quicklisp
http://common-lisp.net/project/cl-test-grid/ql/qlalpha-2014-05-24-diff2.html

In this report find cl-mustache and click on the failure to open the build log.
As you see, most of the time the error is "the variable MUSTACHE-TEST::TEST-MUSTACHE-DEFINE is unbound."

Using the following data:

((:name . "zulu")
 (:list . (1 2 3)))

and the following template:

{{#list}}{{name}}{{/list}}

I'd expect to see:

zuluzuluzulu

But instead I get an error:

There is no applicable method for the generic function
  #<STANDARD-GENERIC-FUNCTION MUSTACHE::DATA (1)>
when called with arguments
  (1).
   [Condition of type SB-PCL::NO-APPLICABLE-METHOD-ERROR]

If you attempt the same in the demo I see the expected result.
Here's the json I used:

{
  "name": "zulu",
  "list": [ 1, 2, 3]
}

I think this should be expected functionality based on

If there is no name key, the parent contexts will be checked recursively.
from the spec.

Thanks!

Running on Debian Linux, sbcl 1.3.7, loading from quicklisp as a dependency of another system.

; file: quicklisp/dists/quicklisp/software/cl-mustache-20150923-git/mustache.lisp
; in: DEFUN READ-TEXT
; (TYPE SYMBOL TYPE)
;
; caught ERROR:
; Lock on package COMMON-LISP violated when declaring the type of TYPE while in
; package MUSTACHE.
; See also:
; The SBCL Manual, Node "Package Locks"

So the compiler could better optimize them.

On some lisp implementations, you will get a compiler warning regarding *mustache-output*. It is defvar'ed in compat-api-v1.lisp, which loads after mustache.lisp. The warning can occur when compiling #'%output in mustache.lisp, which comes before the defvar.

Are there any plans to add this feature?

If we could find the context stack dynamically then we could use the the render function inside a lambda context sensitively.

Spec says

If the data is not of a list type, it is coerced into a list as
follows: if the data is truthy (e.g. `!!data == true`), use a
single-element list containing the data, otherwise use an empty list.

TODO: Add tests to spec

The implicit iterator should be a special name instead of a special tag so things like

{{#list}}{{.not-implicit}}{{/list}}

doesn't work and things like

{{#.}}{{.}}{{/.}}

works.

It maybe not convenient to use keyword as key. Maybe we should consider to use the key as a string instead of a symbol?

The encoding used by lisp implementation to read source files is often depends on environment.
Example, when cl-mustache doesn't build because the default encoding used by lisp implementation is not UTF-8:
http://cl-test-grid.appspot.com/blob?key=805248

If you want the sources to be more reliably build on systems were UTF8 is not the default encoding, you may specify the encoding in your .asdf files:

#+asdf-unicode :encoding #+asdf-unicode :utf-8

The chapter about source file encoding in ASDF manual:
http://common-lisp.net/project/asdf/asdf/Miscellaneous-additional-functionality.html#Miscellaneous-additional-functionality

P.S. as you probably know already, buidl status of cl-mustache and other libraries on different lisps may be found here:
http://common-lisp.net/project/cl-test-grid/library/

' is actually not specified in HTML 4 and ' is recommended in its stead:
http://www.w3.org/International/questions/qa-escapes#use

Hi Kanru,

it's me again. Sorry that I didn't follow up on my previously reported issue: I already removed the code for reproducing the issue and I was only continue where Ileft months after - so no traces left.

The new one at least can be reproduced easily, but I'm not sure whether it's a bug at all:
I was trying to use the implicite iterator '.' in the unescaped/triple version {{{.}}} and found that the triple-info is get lost when the token is generated.

But all samples I found were only using {{.}}, so no hint whether {{{.}}} should be supported at all. The spec only mentions:

Implicit iterators.
A single period (.) may now be used as a name in Interpolation tags,
which represents the top of stack (cast as a String).

Anyway, if you want to support it, the required change would be:

(define-mustache-character #\.
   (make-instance 'implicit-iterator-tag :text arg-text :escape escapep))

Thanks again for working on that helpful library and best regards,
Frank

Hi, I made some small changes to try and fix #29 and as in the readme did

(ql:quickload "cl-mustache-test")
(mustache-test:run)

But got Package MUSTACHE-TEST does not exist.
I'm not seeing it in the t directory. I'm not sure if this is an issue on my side or if the readme just needs to be updated (unfamiliar with how prove works)

Thanks!

Hi Kanru,

first of all thanks for the library!

When I incorrectly created the mustache environment using something like '((key value)) instead of '((key . value)), I was hit by an error that the escape flag for {{{...}}} had not been correctly evaluated, means that even for the triple-pattern, escape was called.
It turned out that the incorrect environment did lead to the call of '(defmethod print-data (token escapep &optional context) ...)' and that this method forwarded processing to another print-data method with incorrect arguments: instead of calling '(print-data (princ-to-string token) (%output))' I think it's necessary to call '(print-data (princ-to-string token) escapep context)'. The incorrect call passed the stream %output as escape a non-nil flag, so that escape was always called, whereas the proposed fixed won't do this. (Also the context argument was missing.)

While searching, I also found that also '(defmethod print-data ((data symbol) escapep &optional context) ...)' does not pass the context parameter and I think it is necessary to change the body to '(print-data (string data) escapep context)'.

HTH and best regards, Frank

If I try to render template with context where some values are not simple strings, then I receive an error.

Here is example:

INFLECTOR> (mustache:mustache-render-to-string
        "{{var}}"
         `((:var . ,(make-array 0
                :element-type 'character
                :adjustable t
                 :fill-pointer 0))))

The value "" is not of type SIMPLE-STRING.                                                                                                        [Condition of type TYPE-ERROR]

I recently had the need to generate a URL from a mustache template. Because in these cases the values must be url-encoded rather than HTML escaped, it would have been very helpful to have conntrol over the mustache::escape function.
While there's other workarounds for this, I think a worthwhile feature would be for mustache to expose some mechanism for controlling the escaping performed on template renderings.

I think a reasonable implementation could be to define a mustache:*escape-function* variable which callers to mustache:render could bind. And/or, an additional optional or keyword parameter to mustache:render to achieve similar.

I'm happy to implement but I'd like some feedback/thoughts.

Thanks!