Why 'render' method on route replaces '/' to '.' in the name? A bug?

1

I have the folder set up this way:

common/ views/ sample_modal_view.js

sample_modal_view.js

Common.SampleModalView = Ember.View.extend( ...)

I tried use render(‘common/sampleModal’, …) to render this view into an outlet. But it could not find it. Some further investigation reveals that:

container.lookup(‘view:Common/sampleModal’) works

container.lookup(‘view:Common.sampleModal’) does not work

And in render method, it is doing: name = name ? name.replace(///g, ‘.’) : this.routeName;

This does not make much sense. The semantics of ‘/’ and ‘.’ are the same for templates according to resolver.js:

‘template:posts/byline’ //=> Ember.TEMPLATES[‘posts/byline’]

‘template:posts.byline’ //=> Ember.TEMPLATES[‘posts/byline’]

But not the same for views:

‘view:post.index’ //=> App.PostIndexView

‘view:post/index’ //=> Post.IndexView

So we should not be doing this replacement.

A bug?

2

does

container.lookup(‘view:sampleModal’) work?

3

No. Because my app is in a different namespace than “Common”.

4

this is an issue, at one point / was advertised as the namespace seperator.

namespace/template bootstrap/button

unfortunately, rendering with slashes also seemed important. Something such as posts/new, does not mean namespace post template new

To address this, I have extracted nearly all the normalization and naming convention rules into the ember resolver The one glaring omission is the / → . normalization, this was done to preserve backwards compatibility, but will likely be deprecated in the future.

As essentially all the naming normalization and object lookup occurs in the Resolver, it is quite easier to augment or swap out. The plan is to ship ember with this compatibility compliant resolver, but make it easy to swap out as needs change.

For example, in the ember-app-kit we wanted to shed some of the old naming convention cruft, and also resolver directly from a module system (AMD) in this case. Our resolver ends up being relatively simple. we don’t implement the majority of the normalization rules, instead we actually merely “fix” the render / → . transform by performing the operation in reverse

We hope to simplify and unify the container based naming conventions.

<type>:<name>@<namespace>` // format

// examples
'controller:posts' // namespace is inferred to be the current one
'view:button@bootstrap' // pull a button form the bootstrap namespace
`controller:nested/in/a/sub-directory`
`template:components/x-fast-slider'

the ember app kit follows this convention, with the exception of namespace, and it seems to be working quite well.

5

Thanks for the explanation. Now I know I am not crazy. :smile:

The way I solved this problem was as you described, I overwrote DefaultResolver and added a new separator which essentially performs the same functionality as ‘/’, but will not be replaced in render().

But this does look like an issue for me, because this means DefaultResolver wouldnt work if you:

  • use namespace
  • use route.render to explicitly pick a view

I think for a complex deployment, this will very likely to occur …

6

1.1 will likely have the namespace solution similar to what I described above.