How to reference Views in Handlebars helper? about ember-app-kit

[thomasboyt]

We'll document this (along with other naming conventions) soon, but it's actually:

{{view "my-view"}}

which corresponds to a file named views/my-view.js :)

[jayphelps]

Yikes, I hate hyphens. Thanks for your help.

[thomasboyt]

hehe, well feel free to UpperCase your filenames if you prefer that (though they still need to be wrapped in strings)

[jayphelps]

Still not working.

Using views/some-view.js and {{view "some-view"}}

Assertion failed: Unable to find view at path 'some-view'

With Ember.ENV.LOG_MODULE_RESOLVER = true I see the hits and misses but some-view never reaches the resolveOther method to log either.

[thomasboyt]

hmm, just tested and you're right. looks like it should work if you remove the hypen, though (views/someview.js and {{view "someview"}}. might be a bug in the resolver? (cc @stefanpenner)

[jayphelps]

@thomasboyt Did you try views/someview.js with {{view "someview"}} ? It's not working for me either. It never reaches the resolveOther method.

[jayphelps]

It's definitely included as it shows up here: define.registry['appkit/views/someview']

[jayphelps]

Can we reopen this ticket?

Check out Ember.Handlebars.get:

var handlebarsGet = Ember.Handlebars.get = function(root, path, options) {
  var data = options && options.data,
      normalizedPath = normalizePath(root, path, data),
      value;

  // In cases where the path begins with a keyword, change the
  // root to the value represented by that keyword, and ensure
  // the path is relative to it.
  root = normalizedPath.root;
  path = normalizedPath.path;

  value = Ember.get(root, path);

  // If the path starts with a capital letter, look it up on Ember.lookup,
  // which defaults to the `window` object in browsers.
  if (value === undefined && root !== Ember.lookup && Ember.isGlobalPath(path)) {
    value = Ember.get(Ember.lookup, path);
  }
  return value;
};

After being normalizePath'd, the root is the controller. Since it's not on the controller, and it's not a global path, the search ends here as far as I can tell.

This ghetto hackery lets this specific view resolve to prove it exists and can be looked up: (though not a real fix for obvious reasons)

window.unknownProperty = function (keyName) {
  return Ember.Namespace.NAMESPACES_BY_ID.App.__container__.lookup('view:' + keyName.toLowerCase());
};

Adding this to Ember.Handlebars.get also solves the issue for all lowercase, single word files:

if (value === undefined && root && root.container) {
  value = root.container.lookup('view:' + path);
}

However, CamelCase or hyphen-ated file names do not work as they get transformed to under_score in the resolver but still registered in their original form. If you guys prefer to lookup registered modules with under_score case, the build process could make sure filenames are registered in that form. Along with the above change to Ember.Handlebars.get, looking up on the container if available, this would be resolved.

Kind of surprised the default implementation of Ember.Handlebars.get doesn't try to resolve views via container lookup already.

[jayphelps]

Found one of the problems. Ember rc7 does resolve views from the container, as needed, but rc6.1 is included in appkit.

@stefanpenner's commit:

emberjs/ember.js@ae116fa

Using rc7 fixes the issue with {{view "someview"}} but doesn't fix the issue of resolveOther expecting all registered modules to be under_score but the build process does not transform filenames into that form.

For anyone stumbling on this ticket, updating Ember to RC7 and removing the underscore(name) call inside loader.js resolveOther() solves this issue for me entirely, so far. (allowing you to use CamelCase, hyphen-ated, under_score, or whatever you want for filenames)

[thomasboyt]

ah! that would explain why I couldn't reproduce your issues; I was using a fresh install w/ RC7.

that underscore call seems well intentioned (presumedly it's there so you can say {{view "SomeView"}} and it would load views/some_view.js) but if we keep it we definitely need to document it. thanks for looking into this :)

[jayphelps]

What about letting users decide their file name convention? Feels very forced for no real benefit.

On Aug 17, 2013, at 8:44 AM, Thomas Boyt [email protected] wrote:

ah! that would explain why I couldn't reproduce your issues; I was using a fresh install w/ RC7.

that underscore call seems well intentioned (presumedly it's there so you can say {{view "SomeView"}} and it would load views/some_view.js) but if we keep it we definitely need to document it. thanks for looking into this :)

—
Reply to this email directly or view it on GitHub.

[stefanpenner]

I'm glad the rc7 addition was noticed, it (and many other related improvements) where driven directly by EAK and using EAK on real apps.

@jayphelps this may not yet be 100% accurate but the goal is to provide a default resolver that provides solid conventions and consistency. For naming throughout your project, and throughout ember. Ideally all major naming conventions (within reason) will be controlled by the resolver. This should satisfy the "you shouldn't need to concern yourself with trivial choices" and the "I want to opt back into trivial choices" requirements.

Now that I am back from vacation, I hope to finalize ^ in the next little while.

[Nininea-zz]

I have the same problem, but only in internet explorer
http://stackoverflow.com/questions/36029620/ember-unable-to-find-view-in-internet-explorer

here are versions i use:
version: 0.0.40
node: 0.12.0
npm: 1.4.29

view helper in template:
{view "wizard-menu" activeIndex=0 parameter=0}}