rip747 / mustache.cfc Goto Github PK

One of the issues with the way that a component can extend the Mustache.cfc and use it's public members as context, is all public methods end up being available as lambdas.

This means the Mustache methods of init, render, getPartials and setPartials all are available. If you end up with a template that has the text "{{init}}" in the code, then CF ends up throwing an error because the "init" function tags a struct as an optional argument (not a string.)

The bigger issue is that these public methods shouldn't even be allowed to be part of the context.

One way to solve that would be to filter out these public methods from being included as context. This would fix the problem, but it does limit templates from ever using these keys as valid context (which could be problematic for some corner use cases.)

We probably also want a way to register other public methods that should be excluded from context--in cases where you've extended Mustache w/additional functionality.

Is this a shortcoming that anyone else has discovered with the CF implementation?

http://jsfiddle.net/ZG4zd/20/ (found via StackOverflow)

This lib does not reach up the chain into the parent scope and beyond; it's my belief that feature is required to maintain spec compliance with Mustache.

Has anyone else run into this that has a solution? I'd love to explore some ideas around it, even if it not deemed valid for this repo.

Right now the lambda function only retrieve the template code as an argument.

However, I started thinking that it would make some sense to pass in a reference to the "context" item as an argument as well, so that you could potentially cache the results of the function call by replacing the context on-the-fly.

This obviously doesn't always make sense, but I have some situations where I have some variables I want to do as a lambda because the lookup expense is costly and they're not always used. By passing in a reference to the context item, I could change the context to point to the rendered string (instead of the function.)

Does anyone else think it's worth adding?

Here's a little proof of concept showing the basic idea would work:

// function to show off lambda
function cacheTest(context, item){
    var results = createUUID();
    // here we cache the results in the original context object
    context[item] = results;
    return results;
}

// a sample context object
context = {test=cacheTest};

for( i=1; i <= 10; i=i+1 ){
    // this logic is handled by the get() method
    if( isCustomFunction(context.test) ){
        x = context.test(context, "test");
    } else {
        x = context.test;
    }
    // show the results
    writeOutput("<div>#i# = #x#</div>");
}

@janders4 submitted a pull request on the original repo: pmcelhaney#8

openbluedragon has a global function called render so the scope this. has to be specified inside mustache.cfc.

render( has to be replaced to this.render(

Hi, I have used Mustache.cfc since Coldfusion, then I moved to Railo without problems but in openBD It comes with this exception.

Type Application
Detail Problem occurred while parsing: render(arguments.inner, ctx)
Extended Info The function render requires at most 1 argument(s).

I see in the code that the render function has the two arguments so the only idea that I could have is some parsing mistake. Any ideas?

There is no mention of the need to install mxunit to have this framework actually work - unless it isn't required, and is only required to make the "tests" folder work - in which case it should still be mentioned somewhere.

Just curious as to why the code is using "loc" as a local scope instead of "local".

Since CF9 actually has a "local" scope, it would seem wisest to convert the code to a more commonly accepted methodology.

Just checking if repo author is dead

Wondering how to handle the (unlikely but possible) case where {{ or }} is needed in a template.

As I understand it, Mustache supports this syntax to change delimiters before compiling:

Mustache.tags = ["[[", "]]"];

It also supports changing delimiters on the fly like this:

{{=<% %>=}}

Far as I can see, neither of those variants are supported by MustacheCFC. Am I right about that? If so, could they be, or are there other alternatives?

Starting up an issue, so we can discuss implementation, as I've been thinking about this a lot.

The issue with converting mustache is that what sections and variables do at runtime differ depending on what the variable is at runtime.

So the way I see this working is that each {{#section}} would need to be converted to a function (probably one that allowed for output to make life super easy). That way you could do type checking at run time to determine what the type of the object is, and then react accordingly.

You would need to store the inner parts of the original mustache template, so it can be passed to lamda's as well.

Anyone see any major issues with that sort of implementation?

This works fine, iterating over the elements in an array:

data = {arr=[10,20,30]};
template = "{{##arr}}{{.}}{{/arr}}";
writeOutput(mustache.render(template, data));

How can you show just element 2, say? Not with any of these seemingly intuitive constructs:

template = "{{arr.2}}";
template = "{{arr[2]}}";

My actual use case is more like this:

data = {arr=[{a=10, b=11}, {a=20, b=21}]};
template = "{{arr.2.b}}"; // or whatever would work to output '21'

The similar case of addressing a specific struct item does work, for instance:

data = {s={a=10, b=20, c=30}};
template = "({{s.b}})"; // -> '20'

Is the array element index version of this possible today with some syntax I missed?
If not, is it a reasonable enhancement?

Thanks.

Mustache now has a suite of language-independent unit tests. We should create an adapter to run those tests to make sure we're in compliance.

https://github.com/mustache/spec