linkedin / dustjs Goto Github PK

I'm trying to write a
base template with blocks witch after in a
child template to reuse only some blocks from the base template and I followed global alias help for dust
but when I use them with partial doesn't want to work.

greeting.dust

{<greeting}Hello, Hola{/greeting}   
{<world} Us, Spain{/world}

partial_end.dust

{#names}
  {.} {+greeting/}
{/names}

{#projects}
  {.} {+greeting/}
{/projects}
{>greeting_template/}

partial_begining.dust

{>greeting_template/}
{#names}
  {.} {+greeting/}
{/names}

{#projects}
  {.} {+greeting/}
{/projects}

In only one file it works like this:

greeting_begining.dust

{<greeting}Hello, Hola{/greeting}   
{<world} Us, Spain{/world}
{#names}
  {.} {+greeting/}
{/names}

{#projects}
  {.} {+greeting/}
{/projects}

but I need to separate the blocks in other files.
Can some one help? I there any other way of doing this?
If now there is an real issue with this maybe I can contribute to dust and try to fix this.

PS: from the main examples it seem that blocks are global when included from partials, but this is the other way around.

I'm not sure if this is intentional, but the output from the stringify (js) filter is HTML escaped. For example, given this template:

{foo|js}

And the following JavaScript:

dust.render("my-template", {foo: {bar: "baz"}}, function(err, out) { console.log(out); });

The console will show:

{"bar":"baz"}

This might be useful for display on a webpage, but I'd argue a far more common use case for this filter is making server-side data available to client-side JavaScript (e.g. embedding JSON data in a script tag). For example:

<script>
  var foo = {foo|js|s};
</script>

Note that to make the above code work, I had to add a second s filter. This is confusing and unexpected, so my vote is to make unescaped the default for the stringify filter.

given JSON

{
  "person": {
    "name": "Larry",
     "age": 45
 },
 "another": {
 in : {
  "name": "Tommy",
  "age": 44
  }
 }
}



  {#person}
    {name}, {age}
      {#another.in} // it is not a block, it is looking for local path, inside of person context
      {name}
      {age}
     {/another.in}
  {/person}

Expected : The above should work and output the data within the block. "another"
Observed: It does not output Tommy 44, instead only Larry 45 is shown

Alternatively,

The following works,

   {#another.in}
     {name}, {age}
   {/another.in}

why? since another is the top level block in the above example, using the . operator works. Any sub contexts using .operator do not work.

The only way to make the above work is reference a subcontext children is via creating a # context

 {#person}
   {name}, {age}..
  {#another}
   {#in}
     {name}
   {age}
  {/in}
 {/another}

{/person}

{> "partial" foo=bar baz="baz"/}

{#block foo=3.4} Hey {/block} is not supported today

fix the grammar

We should allow new line, tab in place of white space?

Atleast support this for inline params

test case

{#pubAuthors
paramName="pubAuthors"
formName=name
defaultContributorFirstName=defaultContributorFirstName
defaultContributorLastName=defaultContributorLastName
coContributors=coContributors
isRequestSecure=isRequestSecure
memberId=defaultAuthorId
maxNumberOfAuthors=maxNumberOfAuthors
addText=i18n_publication_author_add
removeText=i18n_publication_author_remove
maxReachedText=i18n_publication_author_max_reached}
{>"tl/apps/profile/v2/partial/contributors_input"/}
{/pubAuthors}

But the README mentions it. That confused me and might confuse other beginners.

Steps to reproduce:

<script src="https://raw.github.com/linkedin/dustjs/master/dist/dust-full-0.6.0.js"></script>

<script>
    $(function() {
            var compiled = dust.compile("Hello {name}! You have {count} new messages.", "modal");
            console.log(compiled);
    })  
</script>

Expected Output

(function() {
  dust.register("demo", body_0);

  function body_0(chk, ctx) {
    return chk.write("Hello ").reference(ctx.get("name"), ctx, "h").write("! You have ").reference(ctx.get("count"), ctx, "h").write(" new messages.");
  }
  return body_0;
})();

Actual Output

(function(){dust.register("modal",body_0);function body_0(chk,ctx){return chk.write("Hello ! You have  new messages.");}return body_0;})(); 

Notes:

As you see in the actual output, there is no reference to the context as all, so when I push context in, it will still render "Hello ! You have new messages.`

@select helper usage and unit tests

Template:

{do[0]} mr brooks!!

Context:

{
"do": ["Hello", "Bye"]
}

OUTPUT:

{do[0]}

Expected OUTPUT:

Hello mr brooks!!

proposal from @eranl

Works both server side and client side, without any helpers. The idea is to extend the dust expression syntax to support array element entry using brackets (e.g. {a[2].b} ). It's a natural extension of dust.

So your code would look something like:

{#actors}
{@somehelper key="formattedName" type="name.full" args="first:{fn}, last:{ln}"/}
{/actors}

{@anotherhelper key="twoNames" text="{actors[0].formattedName} and {actors[1].formattedName} blah"/}

Today select helper does not support resolving of parmeters before comparing to the eq.lte ...etc

use the tap method to resolve the value, and then compare.

Allow a dust reference to be json.stringifyfied before dust converts it to the string

{<title_A}
AAA
{/title_A}

{<title_B}
BBB
{/title_B}

{+title_{val}/}

The above should work, today it fails to compile

Extra whitespace is generated by Dust tags. This is especially a problem within HTML attributes like "title" for anchor tags, etc.
E.g., I have to remove all line breaks in my TL file like so

{<distanceStr}{@pre.fmt render="false" key="degree_icon_2__text_plain__formatted_name" type="name.full" args="first:{fNameP},last:{lNameP}"/}{@pre.i18n key="degree_icon_2__text_plain__NAME_is_2nd_degree_contact_key" text="{degree_icon_2__text_plain__formatted_name} is a 2nd degree contact"/}{/distanceStr}

otherwise additional white space is created in the rendered output.

add support fo this character, as well see of other characters can be escaped in the content.

This problem exists in both akdubya's dust (0.3.0) and in your dust (0.4.0.) Since it seems 0.3.0 is no longer being maintained, I thought it prudent to ask here. (Thank you for taking this project on!)

I have also posted this question over on SO (http://stackoverflow.com/questions/10339297/dust-js-losing-this-context-in-handlers)

I hope someone will be able to point me in the right direction.

I have a [seemingly] trivial dust.js template. The context object I am using to render the template contains a handler which references another item in the context object. I also include a toString handler, which also references another item in the context object.

Template:

{error}
<pre>
{#error.getStackTrace}
{.}{~n}
{/error.getStackTrace}
</pre>

Context:

{
  error: {
    st: ['a','b','c'],
    msg: 'This is an error message',
    getStackTrace: function () {
      return this.st;
    },
    toString: function () {
      return this.msg;
    }
  }
}

Rendered:

This is an error message<pre></pre>

If I reference {#error.st} directly, it renders correctly:

This is an error message<pre>a
b
c
</pre>

If I inspect 'this' inside of the getStackTrace() handler, it is pointing back to DOMWindow. It is interesting, however, that invoking toString() implicitly, it is scoped correctly. If I explicitly invoke toString() {error.toString}, then the scope jumps back to DOMWindow.

The only reason this is a problem, (why I cannot access error.st directly) is because the st array is actually stored in a Qooxdoo property, and I only have access to the generated getter. The above example mimics the actual object as simply as I can, and yield the same results.

Is this a bug in dust.js? Is it losing the correct scope in handlers? Or am I missing something in the dust.js docs to retain scope?

Thank you!

It would be handy if dust-stream fully implements the ReadStream interface of node.js

http://nodejs.org/api/stream.html#stream_readable_stream

Especially .pipe() is very useful (and DRY, hint hint)

http://nodejs.org/api/stream.html#stream_stream_pipe_destination_options

Illustration:

function onRequest(req, res) {
  dust.stream('main', context).pipe(res)
})

See more details here:akdubya/dustjs#60

Mobile Safari on iOS 4.2 breaks on the 'if' helper method due to Parse error, most likely because "if" is a reserved word. Although it works in 5.0+, simply quoting the method name would fix this.

Add the custom helpers with unit tests

Child template

{>base_template/}
  {#loop}
          {<"var_{$idx}"}
          {/"var_{$idx}"}
  {/loop}

Base template

  {#anotherloop}

          {+"var_{$idx}"}

  {#anotherloop}

for instance looping a list of items and each iteration of the item in a child template creates a different inline partial block ,

so this means a array.list of inline partial blocks can be created as we iterated.

Once created, we can reference the indexed inline partial block in the base template

is this good?

Users view {<name}value{/name} as the definition of a variable value. Currently the can reference it via {+name/} and the value will be output. The compiler will not accept usages like {@ helper param="{+name/} /} so there are a lot of places where the variable cannot be used that one might want to use it.

Relax the compiler grammar to allow a "variable" to be passed via an inline param.

@jairodemorais

Milestone 1.1

We should add a "js perf" test for our fork of the dust to make sure we are not slowing down the dust core

Second, the test.html we have, we should figure out how to expose it as a public page ( like we the original dustjs site exposed )

I have noticed that some of unit tests can be renamed to better documented to express the test case/ feature it is testing

{<default}

Test

{/default}

{+default/}

The above usage of a reserved keyword trips the yui compress since the compiled javascript generated creates default:

{#helper name="Dialog" config="{
'name' : 'index' }
"}
{/helper}

The following is already supported

{#helper name="Dialog" config="{ name: 'index' }"}
{/helper}

From the docs at http://akdubya.github.com/dustjs/#guide :

Dust outputs nothing if the friends key is empty or nonexistent. Let's change that by inserting an {:else} tag, which tells Dust to render an alternate template block when a section key resolves to a falsy value:

Template:

<ul>
{#friends}
    <li>{name}, {age}{~n}</li>
{:else}
    <p>You have no friends!</p>
{/friends}
</ul>

Context:

var context = {
    friends: [
        { name: "Moe", age: 37 },
        { name: "Larry", age: 39 },
        { name: "Curly", age: 35 }
    ]
}

This renders html as expected:

<ul><li>Moe, 37
</li><li>Larry, 39
</li><li>Curly, 35
</li></ul>

However if we change the friends array to be empty,

var context = {
    friends: [ ]
}

the {:else} block does not trigger, we are instead left with an empty

Is this expected behaviour i.e. is my interpretation of "Dust outputs nothing if the friends key is _empty_ or nonexistent" incorrect?

I'm using dust-full-0.6.0.js and compiling these in the browser.

Thanks,

there is a lot of room for improvement on jasmine tests and code coverage.

We would like to publish a code coverage report automatically henceforth

Secondly, add automated IE browser tests if possible.

1. using rhino for a pure jvm solution
2. using v8 ( as part of the node )

Is there going to be a npm package?

I would find it extremely useful rather than having to update through git.

The "if" helper currently parses it's own parameters but we need a generic way of doing so for custom helpers.

I've currently written two functions that i use in my own projects, maybe you could add a dust.parseParemeter or something similar.

/* Replaces {variable} with it's value
* Example : {@Lang key="items.{id}.title" extraparam="{amount}"/}
* Inside my "Lang" helper :  var key = TemplateFillters.renderParameter("key", chunk, context, bodies, params);
*/
renderParameter: function (name, chunk, context, bodies, params) {
    if (params && params[name]) {
        if (typeof params[name] === "function") {
            var output = "";
            chunk.tap(function (data) {
                output += data;
                return "";
            }).render(params[name], context).untap();
            return output;
        } else {
            return params[name];
        }
    }
    return "";
},

/* Same but also executes javascript in {{code}}. Uses a function and not eval.  */
execParameter: function (name, chunk, context, bodies, params) {
    var output = "", pending = false, code = "";
    if (params && params[name]) {
        if (typeof params[name] === "function") {
            chunk.tap(function (data) {
                if (data.indexOf("{") >= 0 || data.indexOf("}") >= 0) {
                    if (data.indexOf("{") >= 0) {
                        output += data.substring(0, data.indexOf("{"));
                        pending = true;
                    }
                    if (data.indexOf("}") >= 0) {
                        code += data.substring(data.indexOf("{") + 1, data.indexOf("}"));

                        var exec = new Function ("chunk", "context", "bodies", "params", "return (" + code + ")");
                        output += exec(chunk, context, bodies, params);
                        code = "";
                        pending = false;

                        output += data.substring(data.indexOf("}") + 1);
                    } else {
                        code += data.substring(data.indexOf("{") + 1);
                    }
                } else {
                    if (pending) {
                        if (!isNaN(data)) {
                            code += data;
                        } else {
                            code += '"' + data + '"';
                        }
                    } else {
                        output += data;
                    }
                }
                return "";
            }).render(params[name], context).untap();
        } else {
            output = params[name];
        }
    }
    return output;
}

The newly created GitHub pages for LinkedIn's dust.js fork contain multiple different ways to spell dust.js. You should pick one and stick to that.

On the front page I can see these different versions:

Dustjs
Dust
dust.js

I would personally choose either Dust.js (with capitalization) or dust.js.

You cannot write a helper of the form {@Helper params /}. You have to write {@Helper params}{/helper}. Granted, some use cases favor the begin/end tag pattern, but there are others where no contained body is wanted or needed. Please consider a compiler change to allow a self-closing helper.

I've constructed a filter that outputs the number of items of a submitted list:

{list|size}

When the list is empty, the filter is not invoked, instead the placeholder is replaced by an empty string.

Would be helpful to leave it to the filter function to decide what is to do in that case.
(e.g. returning 0 in the size case)

When I'm running the serverside jasmine test-suite I'm always getting this result:

[zap@meg server]$ node specRunner.js
undefined

Finished in 0.006 seconds
0 tests, 0 assertions, 0 failures

This happens on my Windows7 machine as well as on every other Linux Server I ran it.

Am I missing a dependency?

The client side tests are running well.

refactor the if helper and abstract the "chunk.tap" to its own helper

       /**
     * Utility helping to resolve dust references in the given chunk
        */
     var tap = function( input, chunk, context ){
        // return given input if there is no dust reference to resolve
        var output = input;
        // dust compiles a string to function, if there are references
        if( typeof input === "function"){
          output = '';
         chunk.tap(function(data){
          output += data;
         return '';
         }).render(input, context).untap();
        } 
       return output;
     }

can we use the

--track-line-and-column
Makes the parser track line and column (available as line and column variables in the actions and predicates).

isn't this useful for tracking line and column numbers.

Outputting
1 2 3
is not possible at the moment.

$idx provides a zero indexed value but there is no way to add 1 using logicless dust

Proposal:
Add a $counter variable

 {#loop}
   {$counter}
 {/loop}

Allow loops to have a special parameter startsIndex

 {#loop startsIndex=1}
    {$idx}
 {/loop}

But,
{>"embed" test="FOOOO"/}
{>"embed" test="BARRR"/}

The above works fine

Now, I tried
{>"embed" test="FOOOO"/}
{>"embed" test="BARRR"/}

{>"embed" test="{foo}"/}
{>"embed" test="{bar}"/}

This prints the value of bar in the json, in all 4 cases.

Hey All,

We are using the https://github.com/akdubya/dustjs version of dust js in our grails project and we would like to move to the linked in version of this project.

The problem is we created a plugin to precompile templates, which evals a slightly modified version of the dust-full.js file. This works fine. But due to the linkedin version hijacking the 'if' reserved word for the builtin helpers you can't eval the script. The code that is evaling the script in the plugin can be found here: https://github.com/zlegein/dustjs-plugin/blob/master/grails-app/services/DustjsEngineService.groovy

Is there a workaround for this or can you think of a way we can do this with the linkedin. I realize using node would be one way of doing this, but I don't see why we need node just for this.

Thanks,
-zach

It is useful to use a context inspect helper and print the current stack in the dust runtime.

Additional info can also be added to this helper for debug purposes

Tags should be used when a new release is made

With recent update to a new pegjs version,

cache=true is not good as the author seems to indicate.

Hence refactor the parser not to rely on the same. Fix any grammar dependencies.

Try to use -track line and column option for cleaner error reporting

Although not critical, since we always serve precompiled templates from CDN, it would be interesting to investigate why the compile time for a sufficiently large template is high with peg.js

It may benefit our dev on the fly compile timings. Not a issue in prod, since we only serve the precompiled template to browser in prod.

Investigate to alter the dust grammar to support arbitrary space ..

Now Invalid gramar

{#a root1="p1" r2="p2" }

{/a}

Compare the syntax with handle bars or mustache and see how they do it ?

currently you can essentially define all your global contexts and helpers when you define makeBase, but in order for the global helpers and contexts to be accessible during rendering, you'd have to do use base as the main context, using

base.push({foo:bar})

in your render method. this makes it verbose. my assumption is, if you've set stuff to global, then you'd want them accessible globally in all your templates, so doing the above might just be a hassle. if this is acceptable, i'll issue a pull request with fixes soon

Got bit with this. Current build in the dist folder is out of date and does not support {$idx} inside @if helper.

What if we can use single quotes for the inline params instead of double quotes

{#block a='a1' }

{/block}

Some have expressed that adding helpers for logic pollutes the logic-less ness of dust!

We should make the if and select helper as an extension to the core dust.

Is there a way to have a flag on the npm install to optionally include helpers such as if and select.