Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Nested template can't access named variable from parent template #12742

Closed
sethladd opened this issue Aug 26, 2013 · 14 comments
Closed

Nested template can't access named variable from parent template #12742

sethladd opened this issue Aug 26, 2013 · 14 comments
Labels
closed-not-planned Closed as we don't intend to take action on the reported issue P1 A high priority bug; for example, a single project is unusable or has many test failures
Milestone

Comments

@sethladd
Copy link
Contributor

Consider this code:

<template id="tmpl" bind>
  <div>Name is {{name}}</div>
  <ul>
    <!-- The color in colors syntax is used with ExpressionSyntax. -->
    <template repeat="{{color in colors}}">
      <li>
        Your name is {{name}} and your favorite color is {{color}}
        <template if="{{color == 'red'}}">
          I found red for {{name}}
        </template>
      </li>
    </template>
  </ul>

The above works with polymer.js but does not work with polymer.dart

Here's the error:

Exception: EvalException: variable not found: name in 446088869
  _DefaultZone.handleUncaughtError.<anonymous closure> (dart:async/zone.dart:146:7)
  _asyncRunCallback (dart:async/event_loop.dart:9:15)
  _asyncRunCallback (dart:async/event_loop.dart:13:7)
  _createTimer.<anonymous closure> (dart:async-patch/timer_patch.dart:8:13)
  _Timer._Timer.<anonymous closure> (file:///Volumes/data/b/build/slave/dartium-mac-full-trunk/build/src/dart/tools/dom/src/native_DOMImplementation.dart:248:17)

Here's the code:

https://github.com/sethladd/dart-polymer-dart-examples/commit/5ee76bbff4d8c65a0a24f975628b7093a05ab7a7

@sethladd
Copy link
Contributor Author

Using Polymer 0.5.5

@sigmundch
Copy link
Member

I believe this is probably a missing feature in polymer expressions.


cc @justinfagnani.
Added Library-PolymerExpressions label.

@sethladd
Copy link
Contributor Author

Ah, yes. Sorry, forgot the sub-label.

@larsbak
Copy link

larsbak commented Aug 27, 2013

Added this to the M7 milestone.

@sethladd
Copy link
Contributor Author

@sigmundch
Copy link
Member

Removed this from the M7 milestone.
Added this to the M8 milestone.

@sigmundch
Copy link
Member

Marked this as blocking #12664.

@jmesserly
Copy link

Removed this from the M8 milestone.
Added this to the Later milestone.

@sigmundch
Copy link
Member

Removed this from the Later milestone.
Added this to the M9 milestone.

@clayberg
Copy link

Removed this from the M9 milestone.
Added this to the 1.1 milestone.

@sigmundch
Copy link
Member

Removed this from the 1.1 milestone.
Added this to the 1.2 milestone.

@justinfagnani
Copy link
Contributor

Looking closer at this, I don't think this is a bug. Your sample code has two different instances of the binding delegate, each with their own independent scope and no awareness of each other. To make this work we'd have to explicitly search for names in the ancestor DOM hierarchy by looking for a <template> node, getting it's delegate (which might not work if it doesn't have one) and use prepareBinding() to create a binding to the name, which might still fail. I don't think users will run into this in practice now that Polymer is deemphasizing raw <template> use and manually setting binding delegates.


Added WontFix label.

@sethladd
Copy link
Contributor Author

Agreed, this is an old bug. I think I deleted this sample a while ago, for the reason you cite (polymer.js is emphasizing <polymer-element>)

@sethladd
Copy link
Contributor Author

Also, thanks for taking a look! :)

@sethladd sethladd added Type-Defect P1 A high priority bug; for example, a single project is unusable or has many test failures labels Jan 29, 2014
@sethladd sethladd added this to the 1.2 milestone Jan 29, 2014
@kevmoo kevmoo added closed-not-planned Closed as we don't intend to take action on the reported issue and removed resolution-wont_fix labels Mar 1, 2016
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
closed-not-planned Closed as we don't intend to take action on the reported issue P1 A high priority bug; for example, a single project is unusable or has many test failures
Projects
None yet
Development

No branches or pull requests

7 participants