There are times when you use App.Model.reopenClass() on a model (link) and the Ember guides talk about App.Router.reopen() (link). From the Ember guides:
reopen is used to add instance methods and properties that are shared
across all instances of a class. It does not add methods and
properties to a particular instance of a class as in vanilla
JavaScript (without using prototype).
But when you need to create class methods or add properties to the
class itself you can use reopenClass.
When is this necessary/advantageous? Is it not possible to just add everything right up front?
reopenClass is analogous to adding methods to the prototype instead of adding methods on each and every instance of your classes. You can think of them as static variables/methods, instead of instance variables/methods.
It's a major performance gain, and possibly makes more sense for the problem you are solving.
One example where you would reopen a class is that when you want to add properties to an existing default generated class. For example: many instances of ember applications don't extend router class. They just use default router class. But what if you want to add some properties to router class that you want to use somewhere else. reopen is pretty usefull there. This is one use case I can think of.
Also, In the case of Router extending the class is difficult as most of the code within ember just uses router class. Even if you extend, some callbacks/closures will still refer to the older router class.
Related
Is there any design pattern in Rails by which i can use helper methods in models, without using include ActionView::Helpers?
ActionView::Helpers are intended to be used in your view code. If you have code that you want to use in you model and view, I would recommend creating a helper method in your model.
If you want to create a method that is used in multiple models, I would use concerns. Concerns are used to extract common chunks of code from models to DRY them up.
Look here for more info
How to use concerns in Rails 4
http://api.rubyonrails.org/classes/ActiveSupport/Concern.html
An alternative to concerns is to create a superclass for common models to inherit from where you can add helper methods
You can for example call one helper at a time if you want.
ApplicationController.helpers.my_helper_method
How to add base class for built in objects (for example controller, router, ...) in ember?
I need to add properties in all controllers and other objects. When I created my controller, I extend from MyBaseController, but built in controller is extended from Ember.Controller. How to force built in controllers extend from MyBaseController?
If you need to add properties to all instances of a class, you can use reopen and reopenClass features.
To read more, have a look this page from ember guides.
I have read that Ember2 is attempting to remove controllers. I was even linked to this RFC https://github.com/ef4/rfcs/blob/routeable-components/active/0000-routeable-components.md. However, I have been following the tutorial, and they insist on making a Controller. Do we still need to make Controllers or is this out of date?
Controllers are still needed (and thus haven't been deprecated) for two reasons: query parameters, and because components aren't routable yet. You can follow the tutorial's use of controllers without it causing you too much grief later on.
However, if you want to pull ahead of the tutorial, you can use components instead, barring the two caveats above. There is no way around using controllers for query parameters, but you can avoid the lack of routable components using this simple hack:
Let's say you're creating a Route called Dashboard. The tutorial will tell you to create corresponding Controller and Template as well. Go ahead and do that, but delete the Controller. Create a component called dashboard-main, move the logic from the Controller to the component.js file and the Template to the component's Template. Then, in the Dashboard Template, just refer to the component:
{{dashboard-main items=model foo=foo bar=bar ...}}
Depending on what you're doing in the Route, you still may need the setupController() method (that's still the only way you can move values other than the model from the route to the template so that they can be passed to the component), and of course your controller/component implementation may have other minor changes, but that's the basic gist of it.
To be most ready for when controllers are deprecated, you should avoid them by using components instead.
I'm trying to find best practices for ember 2 related to class defining. I have a few questions...
Are we supposed to be using the ECMA6 "class", or does ember strictly rely on Ember.Object.extend?
If my class is not supposed to be an ember service does that auto make it a Utility?
Do all custom classes belong in Utility, or is it okay to create
another folder for my classes?
More specifically my class is a wrapper for server sent events.
Are we supposed to be using the ECMA6 "class", or does ember strictly
rely on Ember.Object.extend?
I find Ember.js to be a strict framework. But it does not strictly rely on Ember.Object.extend. You can use whatever you want that is valid Javascript.
However, in my experience I would not try to re-implement too much stuff myself. Also, please note not inheriting from Ember.Object will prevent you from using these methods : http://emberjs.com/api/classes/Ember.Object.html.
Do all custom classes belong in Utility, or is it okay to create
another folder for my classes
Why would you create a new folder ? Ember-cli already provides you with Services and Utilities.
We have some plugins that are used throughout a Coldbox application.
Is there a way to globally inject these without having to manually specify the property for each one?
I've looked through the Wirebox docs, but can't see anything relevant. (Entirely possible I'm overlooking something; it's a long and dense page.)
It would seem like decorating the FrameworkSupertype might be a way to do this, but I can't find any mention of doing that.
I'll point out that Stack Overflow also requires logging in and typing a subject :)
There are several ways to accomplish this and honestly any way works.
The first would be to simply call getPlugin("myPlugin") everywhere you want to use it since the getPlugin() method is available in every handler, view, and layout.
The second would be to use mixin injection and place the following at the top of every handler and then access the plugin from the variables scope:
property name="myPlugin" inject="coldbox:plugin:myPlugin";
The third would be to have all your handlers extend a base handler like Joel suggested and place the DI property in your base handler.
The fourth, which you mentioned, would be to use an AOP aspect and bind it to the init() method for every CFC in the handlers directory and set the plugin into the variables scope as an "after" advice.
A fifth option, would be to use an interceptor to listen to the afterHandlerCreation announcement, and manually inject the plugin into the oHandler object.
And a sixth possibility would be to use the requestStartHandler or a the preProcess interception point and place a reference to your plugin in the private request collection (prc) which will also be available in the views and layouts.
So lots of options, and honestly that probably isn't even all of them. Personally, I'd probably use the afterHandlerCreation interceptor, but you should find the one that works best for you and run with it!