Ember inspector support was added for pod models. cc @stefanpenner

This library relies on the ember-dev Ruby stuff. I know that @rwjblue has the knowledge in his head about how to transition properly. I can do it, just point me in the right direction

Calling helpers should be unambiguous. If a template has a hash or positional parameter, it should call the helper, otherwise, it should lookup the variable.

See http://ember-twiddle.com/b3b796e77b72d2e6c816

Tracking issue ember-cli/ember-page-title#20

We either need loud breaking errors, better docs, or both, but I tried putting a template in as templates/_foo-bar.handlebars, adhering to dasherizedness but thinking that underscores are so ingrained that the underscore rule would win for the first char; doesn't seem like I'm the only dudette or dude tripped up by this.

Here:
https://github.com/ember-cli/ember-resolver/blob/master/packages/ember-resolver/lib/core.js#L228-L235

Should ember-resolver have a new breaking compatibility release with Ember 1.11 to solve deprecation in 1.12?

The ContainerDebugAdapter's catalogEntriesByType() method matches objects by just testing whether the type name appears anywhere within the class name. The result is that many false-positives are returned.

eg for model:

var debugAdapter = appInstance.lookup('container-debug-adapter:main');
console.log(debugAdapter.catalogEntriesByType('model'))

returns:

["ember-data/model", "ember-data/serializers/active-model", "ember-data/adapters/active-model", "ember-cli-test-model-waiter/instance-initializers/test-model-waiter", "ember-cli-test-model-waiter", "hub/ember-cli-test-model-waiter/tests/modules/embe…er/instance-initializers/test-model-waiter.jshint", "hub/instance-initializers/test-model-waiter", "action", "operation", "user", "action.jshint", "operation.jshint", "user.jshint", "action-test", "action-test.jshint", "operation-test", "operation-test.jshint", "user-test", "user-test.jshint", __ember_meta__: Meta]

when I'm pretty sure it should just be:

["action", "operation", "user"]

Not sure how this interacts with pods layouts and the comment in there about different prefixes, but to match "normal" layouts, it seems it should be execing against something like RegExp('^[a-zA-Z0-9-_]+\/' + type + '\/(.*)$')

Note: I originally filed this against ember-cli (for some reason) as ember-cli/ember-cli#5002

@rjackson

The new POD structure (#16) is working really well, however the directory structure becomes a little messy with models, as we use the singular name for models and the plural name for controllers/routes.

For example, say we have a post entity, the pod structure would be:

• pods
  • post
    • model.js
  • posts
    • controller.js
    • route.js

But this would be neater:

• pods
  • posts
    • model.js
    • controller.js
    • route.js

Of course one way to achieve this is to override the resolveModel method and account for use of the plural, which I'm currently investigating as a solution.

as @ has meaning already – as a namespace – we should be careful introducing @ as scope doesn't collide.

A note, we have been throwing the idea, although half baked currently, of :: as namespace instead.

When logging the resolving of application elements.

Ember.ENV.LOG_MODULE_RESOLVER = true;

The logging can fail when you have long component/view/template names. The logging code expects the parsedName.fullName.length to be <= 40. If not, then the logging hits an invalid array length exception.

The resolver was looking up "template:components/update-aware-text-field"

So I've upgraded my ember-cli to v0.0.47 and I like to see if I can get it to work with IE8. I follow the instructions on the https://github.com/opsb/ember-cli-ie8-demo. It should work. But It doesn't and what I notice is that ember-resolver being delivered with the ember-cli install is labelled v0.1.7 but in fact what shows up is v0.1.6. I cd into bower_components/ember-resolver and open up the bower file and it states. 0.1.6. Then I go to the project on Github and notice the 0.1.7 tag states its 0.1.6 in its bower.json file. I really want v0.1.7 version of the resolveer because it has some fixes for supporting IE8.

Currently:
templates/some-route.hbs
templates/some-route/partial.hbs

Better:
templates/some-route/template.hbs
templates/some-route/partial.hbs

What do you think?
It would be nice if we could also use the second structure.

I'm trying to import already builded ember-widget library from addepar (https://github.com/timohofmeijer/ember-widgets-shim/blob/master/ember-widgets.js).

Templates are already precompiled and put into TEMPLATES https://github.com/timohofmeijer/ember-widgets-shim/blob/master/ember-widgets.js#L18.
And there is a view with such layoutName https://github.com/timohofmeijer/ember-widgets-shim/blob/master/ember-widgets.js#L480.

The problem is that resolveOther method does not find anything in requirejs.entries (and it is ok, because templates were not imported via require) and calls resolveTemplate method from https://github.com/emberjs/ember.js/blob/v1.5.0/packages/ember-application/lib/system/resolver.js#L252. But normalize method https://github.com/stefanpenner/ember-jj-abrams-resolver/blob/master/dist/ember-resolver.js#L147 converted accordion_group_layout -> accordion-group-layout and template could not be found. Maybe we should return if https://github.com/emberjs/ember.js/blob/v1.5.0/packages/ember-application/lib/system/resolver.js#L127?
If it is a good idea i can submit PR

Some places in our code base we use .detect and .nearestOfType and they broke when we converted. I've patched it by replacing our code with typeClass.superclass.

I've also encountered this with polymorphic relationships with ember data.

I was doing:

needs : [ 'servicesIndex' ]

This was working long ago. Now I have moved to ember-cli, and I got some errors, so while refactoring I renamed my controller (I thought this was right) services/index.js -> services-index.js

But now (after a big refactoring) I realize that ember is (silently unless enabled) creating a new controller, and not using mine! It seems it is indeed looking for services/index.js

So it seems that the refactoring that I should have done is in the needs, changing to:

needs : [ 'services/index']

and not renaming the files.

Is this correct? Why has this changed for ember-cli? Is this documented somewhere? I am not able to find anything related needs for nested resources in the ember changelog (https://github.com/emberjs/ember.js/blob/master/CHANGELOG.md)

I need to colocate the model with the routes, controllers, templates and partials in a pod-structure (see image).

(I have posted this also at: "Organize your ember with pods"http://cball.me/organize-your-ember-app-with-pods/ and at "ember-magic-resolver"https://github.com/bintoro/ember-magic-resolver)

How can I make this possible?

is it really necessary? may be just use {}?

this should help when working with libraries that ship pre-compiled templates. (like addepar's ember-widgets)

Trying to fully utilize pod structure to make stuff cleaner. We would prefer to have nested directories in pods per our services, and we encountered some oddities with adapters.

Structure

pods/service-a/device/model.js

Can't resolve the adapter from inside of

pods/service-a/device/adapter.js

But it can resolve the adapter from inside of

app/adapters/service-a/device.js

Anything we are doing wrong? Anything we can do to override so that we can keep everything in pods? Is this not the ember way at all?

sorry, clearly we are lacking tests.

screen shot of the resolve of parseName, as you can see many things are undefined.

As resolver is bower.json'd via ~0.1.7 anyone updating (and travis builds) will causes breaks.

I have a view called: 'time-left-moment-table-cell-view' and in this I use:

templateName: 'ember-table/time-left-table-cell',

This gives an RangeError: invalid array length, however if I change it to:

templateName: 'ember-table/timeleft-table-cell',

It works.

Is there something wrong with my naming convention?

After the change of dependency to ember 1.5.0-beta.3, I'm getting this message :

bower ember#= 1.5.0-beta.3 ENOENT ENOENT, lstat '/app/.cache/bower/packages/6c52274ebac940c836cec79e11a2d66a/1.5.0-beta.3/composer.json'

I'm using Ember App Kit.

The resolver currently depends on an Ember global. It would be great if it did not, so ordering does not matter during concatenation.

It seems loading broken again?

May be i am doing something wrong but it isn't working for me.
here is test app:
https://github.com/Sinled/ember-tests/tree/master/test-loading/app

i have

application.loading
posts.loading

templates but none of them are actually loading

   Ember      : 1.13.5
   ember-cli  : 1.13.6

Hi,

I installed the Ember CLI addon and removed the Bower package and am now receiving the following deprecation warning:

DEPRECATION: Usage of ember/resolvermodule is deprecated, please update toember-resolver.

I'm running Ember 2.2. Any ideas on how to get rid of this?

Thanks!

When I tried running bundle install, I got following error.

Could not find gem 'ember-dev (>= 0) ruby' in https://github.com/emberjs/ember-dev.git (at master).
Source does not contain any versions of 'ember-dev (>= 0) ruby'

Then I changed
gem 'ember-dev', git: 'https://github.com/emberjs/ember-dev.git', branch: 'master'
To this
gem 'ember-dev', git: 'https://github.com/emberjs/ember-dev.git', branch: 'ruby'

Now that the resolver has been extracted and is in use by EAK and EAKR, we should add tests to ensure that we do not break either application.

I am happy to flesh this out, but I would like a bit of direction on the best way to test the various functions.

I have a controller which is an "orphaned" controller (means: no existing corresponding route) which is called NotificationCollectionController. The controller is placed under app/controllers/notification/collection.js which seems legit to me (please correct my if I'm wrong) and it cannot be found, causing the following error message if I try to get a grip on it by calling this.controllerFor from my ApplicationRoute:

"Assertion Failed: The controller named 'notificationCollection' could not be found. Make sure that this route exists and has already been entered at least once. If you are accessing a controller not associated with a route, make sure the controller class is explicitly defined."

If I rename the file to notification-collection.js and move it up a folder, so that it's placed under app/controllers/notification-collection.js it is found... is this expected behaviour?

i would like to put adapters, serializers and transforms under one directory. i think they belong together and shouldn't be cluttered around in app/
let's say app/data. the folder layout would be:

app/data
  adapters
    application.js
    post.js
  serializers
    application.js
    post.js
  transforms
    raw.js
    currency.js

it would require to add 4 lines of code and shouldn't affect the resolver:

  // if router:main or adapter:main look for a module with just the type first
  tmpModuleName = prefix + '/' + parsedName.type;
  if (!moduleName && name === 'main' && moduleEntries[tmpModuleName]) {
    moduleName = prefix + '/' + parsedName.type;
  }

  // load adapters, serializers and transformers in app/data
  tmpModuleName = prefix + '/data/' + pluralizedType + '/' + name;
  if (!moduleName && moduleEntries[tmpModuleName]) {
    moduleName = prefix + '/data/' + pluralizedType + '/' + name;
  }

  // fallback if not type:main or POD format
  if (!moduleName) { moduleName = prefix + '/' +  pluralizedType + '/' + name; }

@rjackson @stefanpenner what do you think?

podModulePrefix should default to "modulePrefix/pods"

refs ember-cli/ember-cli#2787 (comment)

This might be one for discourse, but wondering how to handle components with templates when in the pod structure (ie not storing them in the templates directory).

At the moment this works, but is a bit weird:

/components/foo-bar.js
/components/foo-bar/template.handlebars

But I'd like something like:

/components/foo-bar/component.js
/components/foo-bar/template.handlebars

or maybe:

/components/foo-bar/index.js
/components/foo-bar/template.handlebars

Is there a way to configure the resolver to handle that / or alternatives?

I am importing ember-resolver in a non ember-cli project.

But I had some problems with the index.js which is using syntax-export-extensions to make it work with the broccoli-babel-transpiler.

May anybody point me in the direction on how to transpile this syntax with the broccoli-babel-transpiler project, I reviewed the ember-cli code but I could not find any information.

Some Ember.js apps needs for default controllers or routes or templates, not generated by Ember.
In my example I use default ApplicationController and MainRoute for all auto generated routes and controllers.

I have been creating some unit tests based on ember-qunit and the testing guide and I thought I could unit test my classes without the need of the application start.

This custom resolver defines a way to find/resolve my classes based on the module register, but it only uses the namespace to get the modulePrefix and podModulePrefix properties.

I am suggesting to setup these settings optionally on the application namespace or in the resolver to be able to unit test independently of the application instance.

I did not attempt to make the PR because of #39

I am getting the next error: Uncaught TypeError: Cannot read property 'match' of undefined.

The error comes from "podBasedComponentsInSubdir" function -> line 202 -> validation (parsedName.fullNameWithoutType.match(/^components/).

WIth some debug I found that the problem is when parsedName.fullName is equal to "helper:@content-helper"

Not sure if is a bug of ember resolver (lack of null validation) or ember itself.

update

I could reproduce it in an isolated environment an seems to happen when a helper is called without parameters.

{{some-helper ''}} -> ok
{{some-helper}} -> error

I am not sure if this resolver has the intention to support the namespace convention as App.TestRoute, but once I heard that the goal of the resolver is being merged to the ember repository, so this is why I am reporting this use case.

My application is not using ember-cli but it uses the ember-jj-abrams-resolver to modularize the code with the default conventions.

The project setup provides the ability to run different isolated scenarios to be able to run the app in different route states with fixture data. For those cases, I have usually used the namespace convention to load all the code in a unique file.

import 'ember';
import 'ember-data/lib/main';
import App from 'app/system/application';

App.initializeModule('views/initializers/application/load_fixtures');
App.initializeModule('views/initializers/application/setup_store');

Ember.ENV.LOG_MODULE_RESOLVER = true;
window.App = App.create({
  LOG_ACTIVE_GENERATION: false
});
App.TestRoute = Ember.Route.extend({
  model: function() {
    return this.store.find('test');
  }
});


App.Router.map(function () {
  this.resource('test', { path: '/' }, function() {
    this.route('result', { path: ':id' });
  });
});

However, a nested route App.TestResultRoute could NOT be resolved with the ember-jj-abrams-resolver. Fortunately, this problem can be easily solved by returning the route within a module define('app/routes/test/result').

I have getting deeper in the code to find a way to fix the problem but could not find a solution because:

• route:test.result is transformed by normalize transformed to route:test/result
• when the resolver cannot find the module, it calls resolverOther method of its Ember.DefaultResolver base class which neither the Ember.DefaultResolver can find it because its parsedName has been transformed.

Calling the defaultResolver with the reverted normalized fullName would resolve the instance but I am not sure how to implement it to cover all the possible cases.

For the following

/app/pods/posts
  view.js
  mytemplate.hbs

Setting the PostsView#templateName neither to posts/mytemplate or mytemplate does not resolve. It is resolved if it's moved into /app/templates/posts/mytemplate.

Is this a known issue?

I can generate a test app if necessary.

Importing the dist/ember-resolver.js library fails because the initializers.js is self executed when Ember.Application is not yet accesible.

We are not using ember-cli, so I do not know if the initializer may be modularized to be used when necessary.

My mind was blown learning about this resolver. I feel given the explosive nature of this beast, that this name is more appropriate. kthxbai

I'm not sure where this needs to go, here or ember issues, since I'm unsure where the problem lies.

Recently I switched to EAK, and now my loading routes are mostly broken. I have the following template (along with route, etc for non loading templates):

loading
map
map.index
map.loading
map.location
map.location.index

Now none of the loading routes work in the application, except for one. When I load map.location from the url, the loading route activates (only from url). I'm using 1.3.0 of Ember, and I tried to recreate the problem, but no luck.

I made sure that the templates.js contains the loading templates, and it does. It just doesn't make sense why it would only load in that case.

Here's a fork of EAK that has something close. When you enter / the main loading template shows, from there if you go to posts or post it will show that same loading template, this also works from url. Now while you are in posts or post, and you click to the other, no loading appears.

If this is a feature we want to support (I've got two use cases), I'm volunteering to implement it.

I love the pod format, it feels much cleaner to define routes/controllers/templates together. However, I feel like ember-data could benefit from a similar structure. I don't think placing the models/adapters/serializers in the same place as the more traditional pods, as the resources are not always tied together in a mutually exclusive format. Would it make sense to add an additional pod format for ember-data related resources to be grouped together?

i.e.

app
  |---data
  |       |---user
  |       |      |---adapter.js
  |       |      |---model.js
  |       |      |---serializer.js
  |       |---post
  |              |---adapter.js
  |              |---model.js
  |              |---serializer.js
  |              |---comment
  |                      |---adapter.js
  |                      |---model.js
  |                      |---serializer.js
  |---pods
  |       |---index
  |       |      |---route.js
  |       |      |---controller.js
  |       |      |---template.hbs
  |       |---posts
  |              |---route.js
  |              |---controller.js
  |              |---template.hbs
  |              |---comments
  |                      |---route.js
  |                      |---controller.js
  |                      |---template.js
  |---services
  |       |---...
  |---components
  |       |---...
  |---helpers
  |       |---...
  |---mixins
  |       |---...

I haven't seen any updated information on the pod format for a while, so I'm not sure what plans are in store, if any.

Unable to find a suitable version for ember-resolver, please choose one:
    1) ember-resolver#~0.1.20 which resolved to 0.1.21 and is required by ember-resolver#2.0.2
    2) ember-resolver#2.0.2 which resolved to 2.0.2 and is required by myproject

I also tried 2.0.3 to the same avail.

Hi guys,
for some reasons, I can't use Ember-CLI, but I'd like to use this part of it.
Unfortunately, I discovered that 'ember-resolver' doesn't follow AMD fully - it uses Ember's global variable instead of requiring it as dependency.
Is it possible to provide additional version with full AMD support ?

Hi, I have project with Ember 1.9 and I try to upgrade it upon Ember 1.12 with new resolver. Its build process depends on gulp.js. I rewrite all to ES6 modules and include new resolver:

import Ember from 'ember';
import Resolver from 'ember/resolver';
import loadInitializers from 'ember/load-initializers';

var Sun = Ember.Application.create({
    LOG_ACTIVE_GENERATION: true,
    LOG_VIEW_LOOKUPS: true,
    applicationName: "SunSay",
    firstRun: true,
    modulePrefix: 'sun',
    Resolver: Resolver
});

loadInitializers(Sun, 'sun');

export default Sun;

So, but I have some issues with loading app:

Do you have any ideas what may be a reason for exception?

My models directory:

app/models
app/models/static_content.js
app/models/profile.js
app/models/user.js

In my case, the lookup which fails the assert is done automatically by ember-data ActiveModelSerializer, which call store.modelFor('staticContent').
The JSON returned by the server contains the root object static_contents.

Reported by @dogawaf in
#20 (comment).

This leads to a lot of deprecation noise when working with Ember 1.13.2.

Happy to submit a PR if this is legit.

As of #13 this problem is still here.
I have the same issue, when I load into a route that takes some time, any loading templates wouldn't load, but if you do it by URL it works.

We're in the process of converting an app from lineman to ember-cli. We have a percent handlebars helper which works fine in lineman, but doesn't resolve in cli.

We define percent handlebars helper in app/helpers:

Percent = ->
  Ember.Handlebars.helper "percent", (whole_number) ->
    whole_number.toFixed(0) + "%"
`export default Percent`

Attempting to use that helper results in this error:

Uncaught Error: <(subclass of Ember._MetamorphView):ember852> Handlebars error: Could not find property 'percent' on object {name: Cincinnati, utilization: 61.1}.

Changing the helper to per-cent fixes this issue. I think I've traced the cause of this issue, but I'm not sure how to fix it.

In ember-resolver/lib/core.js the extended Resolver's resolve method will call Ember's resolveHelper method.

Ember's resolveHelper method checks for the presence of a hyphen.

if (!container || name.indexOf('-') === -1) {
  return;
}

As far as I can tell, due to this it's not possible to have ember-cli resolve a single word handlebars helper. Am I missing something? Thanks for the help!