I would like to see better inspection and debugging tools. The inspector works great, but it comes short when understanding the actual flow of execution as well as inspecting ember objects. Of course, I can use console.log but it just shows an object with a deeply-nested, complicated and difficult to understand structure. Not sure if it’d be better to expand the functionality of the inspector which may make it too complicated or offering a (javascript) toolset which would help out.
@kgish Have you tried the debugger to set breakpoints in your code? There is also a {{debugger}} Handlebars helper. http://emberjs.com/guides/templates/development-helpers/
Here is a guide on debugging: http://emberjs.com/guides/understanding-ember/debugging/
And finally a logging service: Ember - 4.6 - Ember API Documentation
I feel like the debugger is what you’re looking for. Or can you elaborate?
Yes I am aware of these links and find them very helpful indeed. Perhaps a good tutorial showing a couple of hands-on debugging case studies would elaborate things better. I am often very confused when setting a breakpoint where in the general flow I am and where to look in order to trouble-shoot problems.
All the suggestions above in this article seem awesome. Thanks @Panman8201 for taking the time to write them up.
Really hope they’ll be implemented at least some of these one day 
1 Like
Moving the CC’ed people here since I plan on updating the first post when new suggestions come in and I’m not sure if that triggers another notification for them.
CC @rwjblue @trek @stefan I’ve worked with you guys before, would love to hear what you think. I know you’ll be hard critics but I’m open to criticism.
What do you want Ember.Service to have?
Seems like your wish is coming true in Ember 2.0! 
Especially the session management and form validation could use some built in solution.
@loostro After thinking through it, Services will probably solve session stuff. But I’d still like to see form validation built into Ember.
Authentication, authorization, session management, form validation… these are all common tasks that even simple apps must do to some degree. For now, we had to rely on external bundles/plugins or build your own… I think these (and Ember-Data) should be priority nr 1, as they would make the lives of pretty much every EmberJS developer much easier.
A well -thought standard, built into ember, for these tasks, is what I was missing ever since I built my first Ember App.
1 Like
@loostro - These tasks are extremely customized for each environment and likely have no generic solution that could be included by default.
Addons are the solution here. For example, we already have two or three VERY GOOD authentication addons that can be included into ember-cli (and in some cases a globals app) with one or two simple commands.
It much better for us to let these techniques develop independently.
1 Like
I disagree. How is form validation extremely customized? There are limited number of validation constraints you might wish to apply to a field, such as:
- match regex pattern? true/false
- is empty? true/false
- is numeric? true/false
- is integer? true/false
- is float? true/false
- is greater/less than or equal X? true/false
- is greater/less than X? true/false
- is equal X? (== for numbers) true/false
- is same as X? (== for strings) true/false
- …
Ofcourse, there should be a “CallbackContraint” which takes a callback as an argument and expects a boolean response… which should handle all those non-standard scenarios (e.g. when you want… I don’t know… make an AJAX request to check the current weather and based on that validate or invalidate the field).
This is exacly the scenario where a generic well-documented solution would come in handy.
Also, how is authentication non-generic? In almost every case this simplifies to:
- sending the username/password to a service
- getting a token back
- useing that token to authenticate further communication with the server
And on the client side you probably want to:
- get a set of roles from the token
- and authorize based on these roles
The implementation of server-client communication may vary… but this could be simply defined as a callback. The general logic is the same:
- am i not authenticated? → authenticate
- am i already authenticated → get credentials
- am i communicating with server? → send my token/secret/whatever
- am i authorized (client side) to (something)? → check credentials
This is very generic.
1 Like
Not sure if auth is generic enough. What if I don’t want it role based, but rather claim based? Then how do we represent either of those is still another story that I think is specific to each app.
About validations, even though there’re generic solutions (jquery validate, ember-validators, LGTM). All of them are nice and valid each one has its pros/cons, however, I think there’s room for different options on this space and unless we had a clear winner, I wouldn’t think it makes sense to make it part of Ember.
1 Like
Many of the concerns raised could be alleviated by maintaining an in-memory object graph of the application. Such that from any point in the graph (component, router, controller, …) you can navigate up or down the application tree to find what you need instead of all the other hacks used (resolver, needs etc.). You could even have the graph present a search API or path traversal using ‘.’ or ‘/’ as node separators. Ajax loading parts of the app should be part of the engines/sub-apps soution/proposal.
Several of the solutions to these wishes are sketched out in the Engines RFC: https://github.com/emberjs/rfcs/pull/10
Here are my thoughts (wish list) for the road ahead http://infomatrix-blog.herokuapp.com/post/thoughts-on-ember-20
While I’m in favor of some sort of authentication “stuff” shipping with ember, I can tell you that what you outlined is not generic enough (well - at least not for one of my apps).
I have one backend I talk with that requires sending the username and password for each service call. Granted it’s not the mainstream way things are done, but there are all sorts of goofy models out there.
I was able to do it myself with custom adapaters, initializers, services and subclassing route to an ‘authenticatedroute’ class that did what I needed it to.
Heck for some of this stuff a good first stab would be providing ‘cookbook’ type entries on a decent way to roll your own.