Fair enough… probably some of my learning curve frustrations boiled over into the calendar poc exercise. I do like the architectural viewpoint of Ember, especially with components. But, shit… the docs just leave out so many details – most importantly, many (especially at the official Ember site) don’t really indicate very well exactly which file they are working in, or that some pre-work that took place.
It would be nice if addons would be required to work in a vanilla build before they are given direct access to the ember install command.
It would also be nice if a dev / learning ember install were created that was annotated and strung a route (static JSON) to a model, to a component, to a template. The todo exercise is nice, but now outdated with since fixtures are deprecated.
Going through the learning, pluralizations, and where they are used, is still one of the most confusing things. Still not sure if they only go from a route to a model or what. Not sure if I need to make a plural model as well as a singular one… Not sure if I need to name my RESTful services as plural or singular always… Not sure how to, really, handle pluralizations that don’t fit the plural model (e.g. the word: “series”). The docs say to add some code – uhm, somewhere, but don’t really say where and I couldn’t get it to work. A nice little diagram for pluralization use would be fabulous.
Lastly, the weird (IMO) JSON returns: { object: {} } or { objects: [{ }] }
I imagine that the reason is for side loading… which is nice, but that one feature adds a ton more complexity to back end services that, sometimes, cannot be changed. No?
Specifying in the model if the return is a side load of multiple other models or a singular object would be great. I’m sure that a lot of consumers of mobile aggregation services would love it.
Anyhow, let me try out your solution and get back to you. Thanks for the suggestion.