The changes are primarily in what it is searched in the scope

1. If path not found in the current context head, search next level up in context (ie in tail.head)
2. If not found in top context (tail.head===null), then search in Context's this.global

This change relates to how the path is referenced

3. If a value in a path is a function, apply the function before getting path element. eg, foo.funcbar.baz - would call apply on function 'funcbar' before getting property baz. Note that in the expression foo.funcbar that the function is not evaluated - functions are only evaluated if found before the last element of path.

In my opinion, this make data referencing consistent.

Also see issue #270

This code has a few new tests and passes all existing tests.

If you want to use this, you can simply include this gist after your dust import: https://gist.github.com/carchrae/5825054

This PR provides a fix for dotted path resolution within nested context scopes.

I've seen the discussion at https://github.com/linkedin/dustjs/issues/100 but still think there are good reasons for having this functionality.

Motivations:

• Variable names should be resolved in a consistent manner, there shouldn't be two different methods producing different results depending on whether the variable reference is judged to be a path or not.

• Variable name resolution could and should follow the same rules as used for nested scopes in Javascript.

  Scopes can be nested in dust.js using Context.push(..). Nested scopes should be equivalent to the following JS:

  var person = { name: 'John' };
  var settee = { color: 'red' };
  (function() {
      var person = { name: 'Jack' };
      (function() {
          var person = { name: 'Harry' };
          console.log( person.name, settee.color );
      })();
      console.log( person.name, settee.color );
  })();
  

  There is no confusion at any point here about which data item any variable name references, despite some names appearing in three different scopes. Using dotted notation doesn't in any way complicate the situation.

• We make heavy use of Context.push to create local template scopes without polluting the global scope, and often these scopes are nested 3 or 4 deep. It doesn't make sense that templates in a nested scope loose visibility of any variable that requires a dotted path reference, while keeping visibility of those variables that don't.

• The work arounds - {#breaking}{#the}{#path}{#into}{#sections} or using a helper - are ugly and unwieldy.

This PR also addresses problems with incorrect 'this' references when invoking function values.

Dust removes new lines from output HTML as well as any spaces. This is a problem for cases when we have <pre></pre> tags with pre-formatted HTML .

This example code in pre tag

<div class="row">{~n}
 <div class="content">{~n}
    <div class="row">{~n}
      <div class="facets">6</div>{~n}
      <div class="main-content">8</div>{~n}
      <div class="aside">{~n}
        <div class="row">{~n}
          <div class="summary">4</div>{~n}
          <div class="details">6</div>{~n}
        </div>{~n}
        10{~n}
      </div>{~n}
    </div>{~n}
    24{~n}
  </div>{~n}
</div>

will be rendered as :

<div class="row">{~n}
<div class="content">{~n}
<div class="row">{~n}
<div class="facets">6</div>{~n}
<div class="main-content">8</div>{~n}
<div class="aside">{~n}
<div class="row">{~n}
<div class="summary">4</div>{~n}
<div class="details">6</div>{~n}
</div>{~n}
10{~n}
</div>{~n}
</div>{~n}
24{~n}
</div>{~n}
</div>

Note, if I do not include {~n} everything is rendered as one line of text and browser handles line breaks.

Spaces are used for indentation for the code examples. Removing whitespace is making code examples hard to read. It is pretty hard to figure out HTML nesting without indentation.

And example for script tag is:

sometimes there are single line comments within script tag like:

<script>
//this will alert "test"
alert("this is test");
</script>

After dust compilation it will become :

<script>//this will alert "test" alert("this is test");</script>

This will basically break the code by commenting out that line of JavaScript.

The main dust.js documentation says:

To avoid brittle and confusing references, paths never backtrack up the context stack. If you need to drill into a key available within the parent context, pass the key as a parameter.

I take that to mean that given data like this:

{i18n : { firstname : "First Name" },
 people : [
    {"name" : "Moe"},
    {"name" : "Curly"}
 ]}

A template like this should work, but it does not:

{#people i18n=i18n}
    {i18n.firstname}: {name}
{/people}

How do you expose pathed variables to inner contexts?

Currently you can either call cb(), in which case Dust will try to load the original name from cache, or cb(null, src), and Dust will try to compile src and register it under the original name.

Sometimes, you might want to dynamically load one of several templates based on the original name.

This change adds cb(null, compiledTemplate) so you can load any template from cache or the filesystem, register it manually (or not at all), and render it.

The returned template will NOT be registered under the original name.

I was doing untoward hacks, replacing dust.load in dustjacket for internationalization purposes, and this being private now makes that impossible.

onLoad isn't rich enough for my purposes, which otherwise require doing unbelievably ugly things in the cache.

Now that we have fixed:

https://github.com/linkedin/dustjs/pull/127

Another annoying, not so useful thingy...

{

"name" : "Tesla"

} Does the following add any value?

{#name} {.} {/name}

should n't # be strictly for loops and iterations?

I have an issue: Dust doesn't render a result set from MongoDB by Mongoose. But a custom made array of objects renders just fine. What is wrong? Why it happens? How to manage it? I use Windows 7 64bit if it matters.

Here is a code.

This is my controller. Pay attention to two model objects. The first one (custom made) is rendered fine. The second one (obtained from MongoDB) is not rendered.

    router.get('/', function (req, res) {

        Post.find(function (err, posts) {
            if (err) {
                console.log(err);
            }

            //
            // This is rendered just fine
            //
            var model = {
                posts: [
                    {title: "Title1", body: "Body1"},
                    {title: "Title2", body: "Body2"}
                ]
            };

            //
            // This model is not rendered by Dust
            //
            var model = {
                posts: posts
            }

            res.render('posts', model);
        });
    });

A result set from MongoDB that is not rendered. Its Schema:

    var postSchema = mongoose.Schema({
        title: String,
        body: String,
        crAt: { type: Date, default: Date.now },
        upAt: { type: Date, default: Date.now }
    });

My .dust template code:

{>"layouts/master" /}
{<title}
    Posts
{/title}

{<body}
    {>"partials/header" /}
    <div id="container" class="container">

    <ul>
    {#posts}
        <li>
            {.title}
            <br>
            {.body}
        </li>
    {/posts}
    </ul>

        {>"partials/footer" /}
    </div>
{/body}

Related to pull request #99 and issue #98.

Let's discuss how to have the @math helper drive logic that determines what to render.

Options:

1. Have some $mathOut variable that is in scope inside the body of the @math helper

{@math key="{$idx}" method="mod" operand="5"}
    {@eq key="$mathout" value="1"}
     show if $idx mod 5 === 1
  {/eq}
{/math}

1. Add a param inside of @math that changes the output to a boolean (eq, lt, 'gt,ne`, etc.)

{@math key="{$idx}" method="mod" operand="5" eq="1"} 
   show if $idx mod 5 === 1
{/math}

something else?

Hi!

I've added support for Dust's filters to accept arguments. This allows for syntax such as:

{foo|replace:"bar","baz"}

Or even:

{some_text|link_to:"{url}"}

The syntax is the same as that supported by Twig, the popular PHP templating language, and Liquid, which is used by lots of Ruby projects including Shopify. Filter variables are extremely useful when you need to do some simple string manipulation that is too simple to need a helper! Some examples of filters that use variables in Liquid: https://github.com/Shopify/liquid/wiki/Liquid-for-Designers

The change is completely backwards-compatible. All tests still pass. I also added six new tests around the new functionality-- please check them out to get an idea of how filter variables work.

To have something to test with, I did add two filters to dust.filters-- "replace" and "link_to". I understand those probably don't permanently belong in the core but I know there is some movement around filters anyways so hopefully they can find a temporary home in core and migrate on when we have a place for them.

As an unrelated change, I noticed that the browser test suite had some incorrect logic that was removing some of the test cases erroneously, so I've fixed that as well.

As this is a new feature and a backwards-compatible change, I also incremented the minor version, making this Dust 1.3.0.

Thank you for reviewing this change!

Please refer to this stackoverflow issue for full details: http://stackoverflow.com/questions/26352839/linkedin-dustjs-on-node-express-ios-safari

This may not be purely a dust issue, but I am unable to pinpoint where the fault it. Effectively, I have removed all modules and revert the app back to a standard Express setup. The problem persists with dust, but is gone when i replaced the view engine with EJS.

In short, on the first clean GET request, page loading could not be completed when using iOS Safari. Inspector is showing that latter resources are not getting a response. They, will receive the response after 2 minutes.

There seem to be a limit as to the page size before this happens, meaning to say, as I include more js or images after the threshold, they will run into "not getting a response".

Hi,

We are using dust.js

What we are doing?

• We want to show string as it is coming from JSON into input box let say "This is the \n test box \n testing"

Problem

When we write <input type="text" value="This is the \n test box \n testing" /> then

• Text box come with same string including "\n"

When we use dynamic value from object {name: "This is the \n test box \n testing"} and use like <input type="text" value="{name}" /> then

• it shows like "This is the test box testing" which does not have "\n" and that is the problem where our actual data changes and reflect as problem at many places.

Please help asap.

Looks like http://dustjs.com is down. This is the main source of docs for Dust and I can't find a mirror, so it would be great if this could be brought back online.

Hi, thanks for releasing a new version.

Why is v3 a breaking change please? It's not clear to me from the changelog, and there is no migration guide. This would help us upgrade our apps. Thanks!

We have a vulnerability issue (High):

The audit report show the following:

High | Regular expression denial of service Package | glob-parent Patched in >=5.1.2 Dependency of dustjs-linkedin dustjs-linkedin > chokidar > glob-parent

With the template

{name|h|js}{~n}
{name|j|js}{~n}

and the context

{"name": true}

You get the output

"true"
true

So it seems that html escaping turns non-string types into string, but javascript escaping does not.