I think the problem is MVC itself is a confused mess. It means whatever each person wants it to mean, since it's too easy to make up a bunch of reasonable sounding argumentation for whatever you want to do if you use the words model, view, and controller a lot.
EmberJS Confuses Me
41–50 of 142 posts
Re: EmberJS Confuses Me
#42Your examples are incorrect. The Route's model is set as the content of the controller, so all you need to say is #each item in content. Your model is set as the "content" of your controller, so your model is not "nowhere to be found"
Re: EmberJS Confuses Me
#43> The downside to this approach is that your HTML is "compromised", if you will, and many developers don't like that. My thought is that it's already compromised using Handlebars so what's the difference here? Personally I have no issue using the ng-* directives. Some people do, and I respect that. I'm a bit off-topic, but you don't need to "compromise" your HTML with AngularJS, you can place "data-" in front of your…
When I hear this argument I believe the concern is not the syntax of the binding with respect to the HTML spec, but rather the declaration of bindings in HTML at all. So the issue is not "ng-click" vs. "data-ng-click", but that "ng-click" in any form is no different than the pre-JS MVC horrors of onclick="mutateGlobalStateAndPerformIO()"; which is precisely the barbaric approach we thought we were vanquishing. I thin…
In Angular HTML is the view so that's where ng-click and friends go, while other MVC frameworks have view js files. I know people like to be 'unobtrusive' but many JS MVC apps would be useless without JS so there's nothing to fall back to (other than a plz turn on JS message).
Re: EmberJS Confuses Me
#44Your examples are incorrect. The Route's model is set as the content of the controller, so all you need to say is #each item in content. Your model is set as the "content" of your controller, so your model is not "nowhere to be found"
http://jsfiddle.net/sgterban/kDqBs/ - Example
Re: EmberJS Confuses Me
#45While I actually totally agree with the confusion in the router, I want to explain what I see in Ember's MVC: As far as I attempted to implement it in my app ( https://github.com/thomasboyt/noted-app ), it seemed simple enough. Models were data; all they contained was their properties and operations that controlled their properties. I mainly used controllers as the "state" for parts of my app. In Ember, this doesn't…
Seems reasonable, but the Ember team sees it differently... they put state in the router : >Most of your controllers will be very small. Unlike other frameworks, where the state of your application is spread amongst many controllers, in Ember.js, we encapsulate that state in the router. This allows your controllers to be lightweight and focused on one thing.
Well, clearly, they are crazy people.
Nah, kidding. So they're totally right that there's a significant amount of state in the router, in that that's where you define which model and controller (and, depending on how fancy you get, what views and templates) to use on a given page. So those are essentially state.
The state that can make a controller fat is essentially state that's too important for a view but doesn't need to be universal to the page. For example, with my Dropbox controller, the controller has a state property that handles the various permutations of the state of syncing (i.e. it could be doing nothing, currently saving, done saving, failed saving, etc.). This state is set by the controller on the controller, and used by multiple views to determine things like which label a progress modal should have.
For example, if you had a controller representing a list, you might want to keep track of which item is selected on the controller. That way, if there are multiple views that can act on the currently selected item (for example - you might have a list item view that has a template that renders the item, and then a separate view that are buttons that trigger actions that act on the current item), they all have access to it.
Plus, I always think of state defined in a router as being limited to specific pages/routes, whereas some of my controllers are used on several different routes.
Re: EmberJS Confuses Me
#46While I actually totally agree with the confusion in the router, I want to explain what I see in Ember's MVC: As far as I attempted to implement it in my app ( https://github.com/thomasboyt/noted-app ), it seemed simple enough. Models were data; all they contained was their properties and operations that controlled their properties. I mainly used controllers as the "state" for parts of my app. In Ember, this doesn't…
Seems reasonable, but the Ember team sees it differently... they put state in the router : >Most of your controllers will be very small. Unlike other frameworks, where the state of your application is spread amongst many controllers, in Ember.js, we encapsulate that state in the router. This allows your controllers to be lightweight and focused on one thing.
In this case, the "state" that we're talking about is "what state are you in". In other words, the router manages high-level state ("I am looking at a post now"), and provides long-lived controllers with data reflecting that state. So even though there is information about the current state in the controller (and the view), the source of truth about the current high-level state is in the router.
Re: EmberJS Confuses Me
#47Don't give up! Ember has a steep learning curve but once you've got a bunch of it memorized development gets much easier.
Re: EmberJS Confuses Me
#48Instead of controlling the view directly from the controller, the view uses the controller object (proxy to model) in any way it wants allowing you to change the view without changing the controller and same with the controller. I think the issue you are facing is thinking that you are tightly coupled to the controller by using the controller object, depending on what you think about how much coupling is too much coupling you can argue that just using one object might really be decoupling. I'm not sure if I was able to get my point across.
Re: EmberJS Confuses Me
#49Earlier quoted context omitted.
> The team has been rather clear that Ember is Desktop MVC, not web/server based That's orthogonal to what I'm talking about. I agree that their use of the term "MVC" is much closer to the original meaning it had on the desktop (like in Cocoa) than the meaning in server-side frameworks like Rails. But I'm not talking about what MVC means. I'm talking about what kind of applications Ember is intended to be used to bui…
Your assertion is that "Ember is not about desktop apps". Yes, it is entirely about Desktop apps in terms of structure and approach. These apps are built on the web. One look at the Discourse Ember code and I think you'll understand perfectly the confusion I'm writing about. But I'm curious: do you use Ember or are your responses "what you think"
Yes, Edward Faulkner has used Ember heavily and was one of the original contributors back when we started the project.
Re: EmberJS Confuses Me
#50Earlier quoted context omitted.
When I hear this argument I believe the concern is not the syntax of the binding with respect to the HTML spec, but rather the declaration of bindings in HTML at all. So the issue is not "ng-click" vs. "data-ng-click", but that "ng-click" in any form is no different than the pre-JS MVC horrors of onclick="mutateGlobalStateAndPerformIO()"; which is precisely the barbaric approach we thought we were vanquishing. I thin…
> onclick="mutateGlobalStateAndPerformIO()" What's wrong with that? Other than scoping problems (which Angular solves), this is far more in line with classic view-controller than anything else.
Nothing, but some feel rather strongly averse to it, and plainly view this as Angular's self-evident fatal flaw. As I said I do not subscribe to this line of thinking. My allusion to the horror and barbarism of the pre-JS MVC was merely a jape.