load hooks now run hooks defined in ENV #1837
Conversation
|
Did you consider the simpler approach of letting the var loadHooks = Ember.ENV.EMBER_LOAD_HOOKS || {}The general contract is already that the entries in |
|
@jamesarosen Sounds reasonable. I'm actually rethinking this change. To me it seems like the reasonable thing to do would be to rearrange the boot order of Handlebars so that it can be loaded after Ember and get rid of some of the asserts in |
|
I'm all for a Railties parallel in Ember. I'd definitely use that in Ember-I18n. We're also working on breaking an Ember app up into something akin to Engines. I think Rails's approach (making |
|
I'm finding that my particular use case for wanting this change is pretty niche. Is there any reason you can't include your library after ember and just use load hooks? |
|
I don't need load hooks defined before Ember at all. I was just suggesting a simpler implementation. |
|
@jamesarosen I'm back to endorsing this PR. Could you explain original post? Which local variable are you referring to? Just to be clear, it can't be Ember that initializes the ENV.EMBER_LOAD_HOOKS because that's a structure intended to be initialized by libraries loaded before Ember. Maybe I'm not understanding what you're saying? |
|
If you change this line to var loadHooks = Ember.ENV.EMBER_LOAD_HOOKS || {}you should get everything you want without having to duplicate the lookup and iteration logic. |
|
Oh, very good, I'll make the change. On Wed, Jan 23, 2013 at 12:57 PM, James Rosen notifications@github.comwrote:
Alex Matchneer |
This addresses at least one issue in emberjs#1812
Previously, Handlebars (and thus Ember) did not
disambiguate between arguments passed to helpers
in `stringParams` mode, which Ember uses for
data binding.
For example, there was no different between
{{#linkTo post popular}} and
{{#linkTo post "popular"}}.
In both cases, Ember would try to look up the
"popular" property on the current context.
Now, Ember allows you to specify string literals
as arguments. {{#linkTo post popular}} would look
up the "popular" property on the current context
and generate a URL pointing to the model with that
ID.
{{#linkTo post "popular"}} would treat the string
literal "popular" as the model.
This is useful for cases such as filters, where
you may have several different view options
hard-coded in your template:
{{#linkTo posts "all"}}All Posts{{/linkTo}}
{{#linkTo posts "popular"}}Popular{{/linkTo}}
If your router looked like this:
App.Router.map(function() {
this.route('posts', { path: '/posts/:filter' });
});
The "model" for `App.PostsRoute` would default to
`{ filter: <filter name> }`, and the URLs generated
by the `{{linkTo}}` helper would be `/posts/all`
and `/posts/popular` for the examples above.
As of now, only a single dynamic segment is
supported, even when not using `_id`-style segments.
We expect to lift this restriction in the future.
Note that this entire feature is not yet fully
complete and may change before it lands in the
next release of Ember. If you want stability,
please continue to use `.pre4` for now.
refined pre-Ember load hooks
|
jesus christ. letting this die for bow before i break anything else |
4 participants
If a library included before Ember stashes a callback in an array at
ENV.EMBER_LOAD_HOOKS['hookName'], the callbacks in that array will be called fromrunLoadHooks. Useful for libs that need to be loaded before Ember, e.g. Handlebars replacements (stay tuned).