It cannot resolve nested route on the namespace (App.TestListRoute)

[ppcano]

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.

[stefanpenner]

@ppcano i don't think we can support this without ambiguity. This is actually one of the reasons we moved to modules and away from globals.

Will gladly reopen though if a solution exists.