Skip to content
This repository

Context different for partial #182

Merged
merged 3 commits into from 3 months ago
Dethe Elza

Hi folks,

When I have a template, say:

<div>
  {{#each updates}}
    <div class="update">
        {{#if ../user}}
          <div class="name">{{user.name}}</div>
        {{/if}}
        <p>{{text}}</p>
   </div>
  {{/each}}
</div>

And it works fine, but I move the update into a partial:

file: update.handlebars

<div class="update">
  {{#if ../user}}
    <div class="name">{{user.name}}</div>
  {{/if}}
  <p>{{text}}</p>
</div>

And include the partial where the update code used to be:

<div>
  {{#each updates}}
    {{> update}}
  {{/each}}
</div>

I get "TypeError: Cannot read property 'user' of undefined" now. Why would the context be different for a partial containing the exact same code?

Peter Wagenet
Collaborator

I'm not an expert in this, but I suspect the ../user is where you're having problems. The ../ attempts to move into the parent context, but I suspect that the parent context is not passed to the partial. Does it not work to just do {{#if user}}?

Dethe Elza

{{#if user}} doesn't work because I'm in the context of the {{#each}} iteration. Why wouldn't partials get the parent context? I thought they inherited the full context of the caller.

Ben

Yes, I agree, the parent context would need to be passed.

(I've actually accidentally open a separate bug for the same issue (#192) )

Dethe Elza

Is there some way to fix/force/coerce the parent context to be used? This is impacting our use of handlebars in a number of ways (at least I know why it is happening now). It makes partials a lot less useful.

Ben

I tried looking at the source code for handlebars, some of which goes way above my head but I think what's happening is that a partial essentially acts like a separate template.

When invoked, it's like calling a brand new template, with the current context of the caller passed as new context for the partial.

What that means is the partial gets a brand new stack (which is what handlebars uses to maintain nested context), so .. is undefined in the partial/sub-template (the same way .. is undefined at the top of a template, before any nesting).

So I don't think you can force the parent context to be used, I think the handlebars partial loading would need to be rewritten for that.. (maybe when loading a partial depth0 in the partial could inherit the current stack of the caller, but like I said, that part of the code goes a bit above my head :)

Ben

I did manage this hack to go around the problem. Makes the template kinda messy but it does allow you to pass the parent context. All it does is wrap this and .. into an object and sets that object as the context:

Handlebars.registerHelper('subcontext', function( parent, options) {

    if (arguments.length != 2)
        throw new Error("Handlerbars Helper 'subcontext' needs .. as a parameter");

    var subcontext = { obj:this, parent:parent };

    return options.fn(subcontext);
});

Then you can do this:

Template:
{{#subcontext ..}}
    {{> my-partial}}
{{/subcontext}}

my-partial:

{{whatis this label="this"}}                <!-- Shows {obj, parent} -->
Partial
{{#with obj}}                       <!-- Sets obj as this -->
    {{whatis ../parent label="parent"}}     <!-- parent context from calling template -->
{{/with}}

But yeah, it's kinda messy.

Would be great if .. was properly integrated.

source for whatis

aymuras

@doginthehat I think that this workaround doesn't work when invoking inside loop. And yeah it's messy.
This bug should be fixed for sure.

Other idea: What do you think about introducing something like 'absolute paths' so we can always access all variables nevertheless where we are in the context. Now everything in handlebars seems to be 'relative paths'.

Dethe Elza
dethe commented March 07, 2012

Absolute paths would work for me. Simply adding variables during iteration instead of replacing them would work too. Or simply using "this" to scope the iteration variables and leaving the rest of the context alone. Anything that let's me reference the context regardless of whether I'm iterating or in an included partial (or both).

Ben

@marcinmuras Definitely is messy :)

Haven't had the need for an absolute path as such yet. One thing I have had the need for in the past is the top level context - it often has some global settings for rendering the view that need to be used inside loops or subview.

Recently tried to render a tree structure with handlebar, that was a bit painful.

aymuras

Seems that we are talking about same things. I called your 'top level context' as absolute path. Generally we need something to access all variables in loops, partials etc..

Anders D. Johnson

Thanks for the idea, @doginthehat. There should definitely be a native implementation of this feature for Mustache/Handlebars in the future. I came up with a version that's a bit cleaner (@marcinmuras):

Handlebars.registerHelper('$', function ( child, options ) {
    if ( typeof child !== 'object' ) {
        return '';
    }
    child['$_'] = this;
    return options.fn( child );
});

When calling your partial, wrap it in this helper and pass it an argument of a variable in the current content that will become child context, as follows:

{{#$ childContextObject }}{{> yourPartial}}{{/$}}

To access variables from the calling/parent context in your partial, use:

{{ $_.variableInParentContext }}

Variables from the child context object passed above can be accessed as usual within the partial, i.e.:

{{ variableInChildContext }}

You can rename the helper $ or the parent accessor variable $_ to anything you like.

David Calhoun

+1 A native way to access the parent variables from within a nested partial in a loop would be very helpful.

Mundi Morgado

nice workaround @adjohnson916 , thanks!

definitely would love to see this fixed natively

Ben

is there any suggestion from the powers that be (i.e. @wycats) that this could be natively supported by handlebars in the near future?

Wei Gao

I just found another problem may relatived to this one.

I want to use the customize helpers and paritials like what in wiki:

template(context, {helpers: helpers, partials: partials, data: data})

but I found that in paritials the customize helpers are gone, I guess it because the customize helpers didn't passed correctly as the context changed.

for example, in the main:

 Hi, {{> partial}}!

partial:

{{Uppercase name}}

and run it as:

template({name: 'A' }, { helpers: {
                                       'Uppercase': function(name) { return name.toUpperCase(); }
                                   }});

But it reported: Uncaught Error: Could not find property 'Uppercase'

mschipperheyn

This might be interesting: https://github.com/edgarespina/handlebars.java/issues/48#issuecomment-7514533
For me, this issue is becoming more and more a major headache

Ben

@mschipperheyn Thanks, that is interesting. Though I don't think it applies to partials, there is no upper context to navigate to in partials, that's the main issue :)

chickenwing

I wrote a workaround which gives you a little more control as to how access the parent scope inside of the partial

see code example here http://jsfiddle.net/Fz8Tc/

With a context like this

var context = {name: "Dennis", town: "berlin",  hobbies: [{hobbyname: "swimming"}, {hobbyname: "dancing"}, {hobbyname: "movies"}]}

and the following helper

Handlebars.registerHelper('include', function(templatename, options){  
    var partial = Handlebars.partials[templatename];
    var context = $.extend({}, this, options.hash);
    return partial(context);
});

This lets you include a partial like this (from jsfiddle expample):

{{include "template-partial" parentcontext=.. town=../town}}

now town would be accesible inside the partial directly by {{town}} or {{parentcontext.town}}

With the options (key=value) following the templatename ("template-partial") you can kind of map the parent context to any key inside the partial. This makes it easier to change things back, when native support is there.

Dennis

@chickenwing

thanks, looks brilliant!

Ben

thanks @chickenwing

I like it!

(still +1 for native support though)

Ustun Ozgur

@chickenwing Using your helper helped, thanks. I had to change the last line to:

        return new Handlebars.SafeString(partial(context));

otherwise, the html output from the include was being interpreted as text.

(Also, not sure why, but it seems Handlebars is storing my partials as strings, not functions under Handlebars.partials, so I added

if (typeof partial === "string") {
        partial = Handlebars.compile(partial);
}
Brett Fishman

@ustun and @chickenwing - Haha. Struggled with this for a few minutes as well - was about to paste the same solution as @ustun. Here's my full helper code (in CoffeeScript):

Handlebars.registerHelper 'include', (templateName, options) -> 
  partial = Handlebars.partials[templateName]
  if (typeof partial is "string")
    partial = Handlebars.compile(partial)
    Handlebars.partials[templateName] = partial
  context = $.extend({}, this, options.hash)
  new Handlebars.SafeString partial(context)
Leonhardt Wille lwille referenced this pull request from a commit in lwille/handlebars.js November 21, 2012
Leonhardt Wille added 'include' helper from #182 25d1fe4
Leonhardt Wille

done(pullRequest);

#368

rektide

That include helper causes a lot of data copying to happen. It seems insane not to just have the partial operator participate in scope somehow, directly, and to instead keep generating new crazy contexts via hackery like include.

Andrew Henderson

@chickenwing solution is solid, but has a line that bothers me:

Handlebars.partials["template-partial"] = Handlebars.compile( sourcePartial );

A Handlebars compilation has to occur outside of the helper in order for it to work properly.

I think the following solution works well and uses the familiar Helper syntax with a clean partial declaration inside - http://jsfiddle.net/AndrewHenderson/kQZpu/9/

{{#eachIncludeParent context parent=this}}
    {{> template-partial}}
{{/eachIncludeParent}}
Handlebars.registerHelper('eachIncludeParent', function ( context, options ) {
    var fn = options.fn,
        inverse = options.inverse,
        ret = "",
        _context = [];
        $.each(context, function (index, object) {
            var _object = $.extend({}, object);
            _context.push(_object);
        });
    if ( _context && _context.length > 0 ) {
        for ( var i = 0, j = _context.length; i < j; i++ ) {
            _context[i]["parentContext"] = options.hash.parent;
            ret = ret + fn(_context[i]);
        }
    } else {
        ret = inverse(this);
    }
    return ret;
});
Andrew Henderson

Just submitted a pull request. The Helper now has no dependencies outside of Handlebars.
#385

C. Scott Ananian

I like the @chickenwing solution in so far as it also solves a related problem: passing arguments to partials. Much of what is done in code with helpers could be done with partials instead if only I could pass arguments into the partial's context...

Christoph Neuroth
c089 commented March 20, 2013

+1 on what @cscott said: This would allow to use partials instead of helpers which is absolutely essential when sharing templates between different implementations such as handlebars.java on the server-side and handlebars.js on the client. Writing a helper always requires two implementations in that case where the "include" from #368 would often be sufficient.

Christoph Neuroth c089 referenced this pull request in jknack/handlebars.java March 20, 2013
Merged

include helper #140

Olivier Lalonde

I wonder if @wycats is still actively supporting this project. Maybe he should give commit access to someone who would have time to go through the issues.

Jon Schlinkert

Yeah when users submit issues about this on our projects we have to keep explaining that "it's a handlebars problem". IMO this is so obvious it should be considered a bug, not a feature. It would be great to not have to address this anymore.

Anders D. Johnson adjohnson916 referenced this pull request in assemble/assemble-contrib-permalinks October 08, 2013
Closed

Linking to static assets from nested sub directories #21

Laurent Goderre

I'm wondering though, should it be up to each helper that change the context to make sure that the parent context is added to the child?

Laurent Goderre

I looked into doing this without touching the helpers themselves and the problem I am struggling with is the multi threading and the stack part. I was able to append an object to the this object for each helper but the object being added is a JavaScript object for the node thread instead of the handlebars context

Philip Walton

+1 for native support

Is anyone working on a pull request at the moment? If everyone +1-ing tried to take a look at implementing a solution, we'd have something by now. I'm happy to give it a go if no one else is...

waynedpj referenced this pull request in assemble/assemble January 11, 2014
Closed

YAML front matter in partials #98

Kevin Decker kpdecker referenced this pull request January 17, 2014
Closed

Partial parameters #410

Kevin Decker
Collaborator

I don't like the ../ support for a variety of reasons. They can add a significant amount of performance overhead as all of the local variables that are used to represent each context need to be packaged and passed to the partial since the caller doesn't know what the partial may need to access. Additionally this feels like a very good way to run into unexpected behavior or issues reusing partials in settings that have different context hierarchies.

I do like the suggestions of augmenting the context that have been made here and in the various linked PRs. This lets the caller opt in to any performance overhead and allows partials to define "api contracts" that the caller can adhere to rather than making assumptions about the context stack that the partial is being called in.

Rather than doing this as a helper as the PRs suggest I'm going to implement this within the partial execution logic itself so we can have one defacto method of accessing partials.

{{> foo bar=.. }}.

Kevin Decker kpdecker merged commit 363cb4b into from January 17, 2014
Kevin Decker kpdecker closed this January 17, 2014
Kevin Decker kpdecker deleted the branch January 17, 2014
Yehuda Katz
Owner

@kpdecker I have always preferred "partial interfaces" to the risks of ..'ing into an arbitrary parent.

:+1:

Kevin Decker
Collaborator

Released in v2.0.0-alpha.1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
This page is out of date. Refresh to see the latest.
3  lib/handlebars/compiler/ast.js
@@ -97,11 +97,12 @@ var AST = {
97 97
     // pass or at runtime.
98 98
   },
99 99
 
100  
-  PartialNode: function(partialName, context, strip, locInfo) {
  100
+  PartialNode: function(partialName, context, hash, strip, locInfo) {
101 101
     LocationInfo.call(this, locInfo);
102 102
     this.type         = "partial";
103 103
     this.partialName  = partialName;
104 104
     this.context      = context;
  105
+    this.hash = hash;
105 106
     this.strip = strip;
106 107
   },
107 108
 
10  lib/handlebars/compiler/compiler.js
@@ -203,8 +203,14 @@ Compiler.prototype = {
203 203
     var partialName = partial.partialName;
204 204
     this.usePartial = true;
205 205
 
206  
-    if(partial.context) {
207  
-      this.ID(partial.context);
  206
+    if (partial.hash) {
  207
+      this.accept(partial.hash);
  208
+    } else {
  209
+      this.opcode('push', 'undefined');
  210
+    }
  211
+
  212
+    if (partial.context) {
  213
+      this.accept(partial.context);
208 214
     } else {
209 215
       this.opcode('push', 'depth0');
210 216
     }
2  lib/handlebars/compiler/javascript-compiler.js
@@ -569,7 +569,7 @@ JavaScriptCompiler.prototype = {
569 569
   // This operation pops off a context, invokes a partial with that context,
570 570
   // and pushes the result of the invocation back.
571 571
   invokePartial: function(name) {
572  
-    var params = [this.nameLookup('partials', name, 'partial'), "'" + name + "'", this.popStack(), "helpers", "partials"];
  572
+    var params = [this.nameLookup('partials', name, 'partial'), "'" + name + "'", this.popStack(), this.popStack(), "helpers", "partials"];
573 573
 
574 574
     if (this.options.data) {
575 575
       params.push("data");
7  lib/handlebars/compiler/printer.js
@@ -82,7 +82,12 @@ PrintVisitor.prototype.mustache = function(mustache) {
82 82
 
83 83
 PrintVisitor.prototype.partial = function(partial) {
84 84
   var content = this.accept(partial.partialName);
85  
-  if(partial.context) { content = content + " " + this.accept(partial.context); }
  85
+  if(partial.context) {
  86
+    content += " " + this.accept(partial.context);
  87
+  }
  88
+  if (partial.hash) {
  89
+    content += " " + this.accept(partial.hash);
  90
+  }
86 91
   return this.pad("{{> " + content + " }}");
87 92
 };
88 93
 
8  lib/handlebars/runtime.js
@@ -29,8 +29,12 @@ export function template(templateSpec, env) {
29 29
 
30 30
   // Note: Using env.VM references rather than local var references throughout this section to allow
31 31
   // for external users to override these as psuedo-supported APIs.
32  
-  var invokePartialWrapper = function(partial, name, context, helpers, partials, data) {
33  
-    var result = env.VM.invokePartial.apply(this, arguments);
  32
+  var invokePartialWrapper = function(partial, name, context, hash, helpers, partials, data) {
  33
+    if (hash) {
  34
+      context = Utils.extend({}, context, hash);
  35
+    }
  36
+
  37
+    var result = env.VM.invokePartial.call(this, partial, name, context, helpers, partials, data);
34 38
     if (result != null) { return result; }
35 39
 
36 40
     if (env.compile) {
2  spec/ast.js
@@ -193,7 +193,7 @@ describe('ast', function() {
193 193
   describe("PartialNode", function(){
194 194
 
195 195
     it('stores location info', function(){
196  
-      var pn = new handlebarsEnv.AST.PartialNode("so_partial", {}, {}, LOCATION_INFO);
  196
+      var pn = new handlebarsEnv.AST.PartialNode("so_partial", {}, {}, {}, LOCATION_INFO);
197 197
       testLocationInfoStorage(pn);
198 198
     });
199 199
   });
8  spec/parser.js
@@ -84,6 +84,14 @@ describe('parser', function() {
84 84
     equals(ast_for("{{> foo bar}}"), "{{> PARTIAL:foo ID:bar }}\n");
85 85
   });
86 86
 
  87
+  it('parses a partial with hash', function() {
  88
+    equals(ast_for("{{> foo bar=bat}}"), "{{> PARTIAL:foo HASH{bar=ID:bat} }}\n");
  89
+  });
  90
+
  91
+  it('parses a partial with context and hash', function() {
  92
+    equals(ast_for("{{> foo bar bat=baz}}"), "{{> PARTIAL:foo ID:bar HASH{bat=ID:baz} }}\n");
  93
+  });
  94
+
87 95
   it('parses a partial with a complex name', function() {
88 96
     equals(ast_for("{{> shared/partial?.bar}}"), "{{> PARTIAL:shared/partial?.bar }}\n");
89 97
   });
8  spec/partials.js
@@ -23,6 +23,14 @@ describe('partials', function() {
23 23
     shouldCompileToWithPartials(string, [hash, {}, {dude: partial}], true, "Dudes:  Empty");
24 24
   });
25 25
 
  26
+  it("partials with parameters", function() {
  27
+    var string = "Dudes: {{#dudes}}{{> dude others=..}}{{/dudes}}";
  28
+    var partial = "{{others.foo}}{{name}} ({{url}}) ";
  29
+    var hash = {foo: 'bar', dudes: [{name: "Yehuda", url: "http://yehuda"}, {name: "Alan", url: "http://alan"}]};
  30
+    shouldCompileToWithPartials(string, [hash, {}, {dude: partial}], true, "Dudes: barYehuda (http://yehuda) barAlan (http://alan) ",
  31
+                    "Basic partials output based on current context.");
  32
+  });
  33
+
26 34
   it("partial in a partial", function() {
27 35
     var string = "Dudes: {{#dudes}}{{>dude}}{{/dudes}}";
28 36
     var dude = "{{name}} {{> url}} ";
3  src/handlebars.yy
@@ -63,7 +63,8 @@ mustache
63 63
   ;
64 64
 
65 65
 partial
66  
-  : OPEN_PARTIAL partialName path? CLOSE -> new yy.PartialNode($2, $3, stripFlags($1, $4), @$)
  66
+  : OPEN_PARTIAL partialName param hash? CLOSE -> new yy.PartialNode($2, $3, $4, stripFlags($1, $5), @$)
  67
+  | OPEN_PARTIAL partialName hash? CLOSE -> new yy.PartialNode($2, undefined, $3, stripFlags($1, $4), @$)
67 68
   ;
68 69
 
69 70
 simpleInverse
Commit_comment_tip

Tip: You can add notes to lines in a file. Hover to the left of a line to make a note

Something went wrong with that request. Please try again.