Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

EmberJS Confuses Me

wekeroad.com

Post reply on HN
Print view View original

51–60 of 142 posts

Re: EmberJS Confuses Me

#51

Post by MatthewPhillips »

daigoba66 wrote: post #35
xaritas wrote: post #29

Earlier 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.

What happens when you want to add a second, unrelated, thing? Just stick it on the end in the onclick? Create a new function called doTwoThings()? This is one of the reasons I prefer using an observer pattern over MVC.

Re: EmberJS Confuses Me

#52

Post by Tichy »

I think the way controllers work here is similar to Ruby on Rails? It confused me in Rails at first (coming from the Java world), but I think it is essentially just a hack to allow for "easier" passing of data to the view (the controller gets exposed to the view). So instead of scope.whatever = "hello world" you can write this.whatever = "hello world" (OK not really shorter, but something like that).

That usage of Controllers is not part of the MVC pattern, I'd say. It's just a recycling of the controller instance - not forbidden, just confusing if you wonder what it has to do with MVC.

Actually it's also the RoR way to have short lived controllers (a controller is instantiated for every request), other frameworks use one static controller instance instead.

Re: EmberJS Confuses Me

#53

Post by AdrianRossouw »

ef4 wrote: post #23
robconery wrote: post #15

Earlier quoted context omitted.

The controller is the data. The model is grafted onto it for convenience. This ties the view to the model to the controller which is sort of orthogonal to "separation of concerns". In my opinion at least.

> The controller is the data. No, it's not. Because a single controller over its lifetime can be bound to many different models. The controller is glue. It brings together whichever model is appropriate at the moment with whatever view is appropriate at the moment, and makes decisions about when to change those things.

The controller seems to be where you put logic that would have ended up in your templates. ie: more complex conditionals and filtering and the like.

Re: EmberJS Confuses Me

#55

Post by devinrhode2 »

At first read, I thought your point about routing was really good - why not have route('about').template('aboutTemplate').controller('aboutController') - and then I realized this is all reapeating the same mumbo jumbo. This is all automatically matched up by the naming convention (which frustrates me too, but until I figure out a better way...)

Re: EmberJS Confuses Me

#56

Post by jfarmer »

robconery wrote: post #36
jfarmer wrote: post #27

Earlier quoted context omitted.

@rob: The controller should be the data as far as the view is concerned. Otherwise the view knows too much and the controller can't re-proxy a different model.

Knows too much about what? The view lives to present the data to the user - that's all it should know. The fact that the controller is the data is a design problem.

The data could be coming from multiple places and sources, only some of which are "models." This is true in Rails, too.

For the sanity of the view, the controller is the single point where it can get the data. It shouldn't know the nitty gritty details about where it came from, whether it's a "model," or anything else. The view is just, "Gimme the data, controller! Gimme!"

This principle is just as valid in Ember as it is in Rails. The only difference I see is that because the controller and view have to live forever, so to speak, it makes more sense for the view to pull data from the controller rather than have the controller push data to the view.

Maybe think about it this way. How is this any different than rails, really? In Rails you set goddamn instance variables in your controller actions. The view and controller are straight-up sharing state.

How is that less coupled?

This would be like the controller exposing getting and setter methods and instead of typing
you'd type
It seems like Ember does some "nice things" to handle the common cases and that there are additional assumptions, like maybe one model per controller (not sure I understand that), but there you go.

Ember seems less coupled all around than Rails and because of its long-running nature needs the view to poll the controller.

Re: EmberJS Confuses Me

#57

Post by agpen »

tree_of_item wrote: post #41

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.

Yeah, I even wrote my own MVC framework for a small project and I still don't know what MVC is "supposed" to mean because every single implementation example I see is completely different and at odds.

Re: EmberJS Confuses Me

#59

Post by steveklabnik »

blktiger wrote: post #37
robconery wrote: post #19

Earlier quoted context omitted.

The team has been rather clear that Ember is Desktop MVC, not web/server based: https://twitter.com/trek/status/309315009291378690 They say as much in their guides as well.

I'd definitely say that Ember is more Desktop MVC than MVC2. True to it's Sproutcore/Cocoa roots, you are supposed to be able to wire up a lot of the application with the built-in controllers that don't have to be customized (or at least customized very little). Ember is trying to take that approach, make it more familiar to web developers, and add in some additional parts that are part of what makes the internet wor…

> MVC2.

While we're being pedantic, it's Model 2, not MVC2: http://en.wikipedia.org/wiki/Model_2

Post reply on HN