71–80 of 142 posts
> I think Yehuda is a very nice and smart person I always get confused by this. I don't understand how being nice factors into technical decisions? (For the record, I also think wycats is nice, but I don't really care when I'm trying to decide whether or not what he's saying makes sense)
I come from Backbonejs background with which I have worked for about 1.5 years. So I feel quite comfortable with it. I decided to try Emberjs - not for any other reason than trying to pick up something else and see how other JS framework approaches. I gave full two-days worth of time into it. Initially I thought - "How different can it get?" Plus, I believe even if it's very foreign I'll just keep reading, googling,…
The Ember teams has been planning for a sweep of all outdated information about Ember. We'll be updating SO questions and asking blog authors to add a disclaimer. Ember Data is a completely optional component of Ember that seeks to bring ORM-like abilities to the client side. It's not as far along or as stable as core Ember. For what it's worth, you can easily just use jQuery.ajax and create Ember.Objects from the re…
Yes it's optional, and yes you can use jQuery.ajax or whatever, but in reality, it's not quite that simple.
The official guides in Ember default to assuming you're using Ember-Data (though they do at least mention it explicitly). This despite Ember-Data being far from production ready (as stated on the Github page) and far too slow for dealing with large quantities of data. At the same time, the conventions that are found in Ember-Data appear to be built in to core Ember (it says as much in the guides).
As far as Ember-Data not counting against Ember - it may be larger in scope than other client side data libraries (or the M part of other MVC frameworks or whatever) but the fact is that they are most definitely comparable, as it's the way that Ember gets stuff off the server, and saves it back to the server. Without Ember-Data, Ember has no built in way of doing that, which counts against it. With Ember-Data, well, it's not really ready yet, which also counts against it.
I come from Backbonejs background with which I have worked for about 1.5 years. So I feel quite comfortable with it. I decided to try Emberjs - not for any other reason than trying to pick up something else and see how other JS framework approaches. I gave full two-days worth of time into it. Initially I thought - "How different can it get?" Plus, I believe even if it's very foreign I'll just keep reading, googling,…
The Ember teams has been planning for a sweep of all outdated information about Ember. We'll be updating SO questions and asking blog authors to add a disclaimer. Ember Data is a completely optional component of Ember that seeks to bring ORM-like abilities to the client side. It's not as far along or as stable as core Ember. For what it's worth, you can easily just use jQuery.ajax and create Ember.Objects from the re…
But, I really really think for a newbie (like me) to even find out that I can use jQuery.ajax to create Ember.Objects is confusing. The immediate questions following that would be
* How do I do that? Can I see an example? And where do I find a counter-example? * Then why Ember Object (ok fine they provide cool ORM features, but when I'm starting, I just want to understand what/where things are)
I know a lot of people are raving about Emberjs, and personally it looks good and I really want to get into it, but really really really, I found it not-newbie friendly.
Earlier quoted context omitted.
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
Seems like the big confusion about the controller is that it is closer to a ViewModel (think MVVM) than to a Controller itself. Potatos, Potahtos.
To digress a little, it's not much different than the terminology confusion in Backbone, where:
- Router(s) work as front controllers,
- templates (along with the browser's DOM) as views, and
- Views as presenters (from the MVP pattern).
Models are flavored with the Active Record pattern. Presenters and views are tightly coupled.
MVC and MVP coexist because the controllers respond to navigational input (mapping to model-presenter pairs) and the presenters respond to page-specific input (mapping to model manipulations and, possibly, server calls).
Earlier quoted context omitted.
{{#each controller}} {{name}} {{/each}} How is the controller not the data as far as the View is concerned?
As mentioned above, the proxied model data is actually stored in a controller's "content" field. So that snippet is actually just shorthand for {{#each controller.content}} {{/each}}
Earlier quoted context omitted.
> 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.
A more general argument is that any behaviour specified in markup is bad. I'd counter that by saying that it's already there in HTML. Input boxes for example have behaviour intrinsic to their being. So angular let's you create a (for example) richtext tag. You attach behaviour to that tag, say on click. In the HTML it's as clean as . Within the directive you can make it behave as you please.
I think that people see the shortcut directives used in angular (eg Ng-click) and the purists shout "unclean"! The reality is that You can do things a slightly longer way and end up with something thy looks a lot like the observer pattern.
This may be the issue. I think most of us never really wanted to build web applications, but we were forced to do so due to browser and framework limitations.
We really just wanted to build the best damn desktop app possible that just happened to be deployed in a browser via the Web. This might explain our confusion and disappointment when client side frameworks don't deliver on that desire.
Earlier quoted context omitted.
The Ember teams has been planning for a sweep of all outdated information about Ember. We'll be updating SO questions and asking blog authors to add a disclaimer. Ember Data is a completely optional component of Ember that seeks to bring ORM-like abilities to the client side. It's not as far along or as stable as core Ember. For what it's worth, you can easily just use jQuery.ajax and create Ember.Objects from the re…
Without meaning to offend, I'm afraid I have to take issue with your points about Ember-Data. Yes it's optional, and yes you can use jQuery.ajax or whatever, but in reality, it's not quite that simple. The official guides in Ember default to assuming you're using Ember-Data (though they do at least mention it explicitly). This despite Ember-Data being far from production ready (as stated on the Github page) and far t…
I also highly recommend watching one of the follow talks about Ember Data: http://www.youtube.com/watch?v=_6yMxU-_ARs or http://www.youtube.com/watch?v=V8nnE948zxk. Both talks make it very clear that Ember Data is not at all comparable to what is offerred by other frameworks.
Earlier quoted context omitted.
The Ember teams has been planning for a sweep of all outdated information about Ember. We'll be updating SO questions and asking blog authors to add a disclaimer. Ember Data is a completely optional component of Ember that seeks to bring ORM-like abilities to the client side. It's not as far along or as stable as core Ember. For what it's worth, you can easily just use jQuery.ajax and create Ember.Objects from the re…
Cool, thanks for explaining. But, I really really think for a newbie (like me) to even find out that I can use jQuery.ajax to create Ember.Objects is confusing. The immediate questions following that would be * How do I do that? Can I see an example? And where do I find a counter-example? * Then why Ember Object (ok fine they provide cool ORM features, but when I'm starting, I just want to understand what/where thing…
Creating an object instance with AJAX is as simple as just calling `create` with the data provided in the callback. However, you may want to create the object first, then update the object's properties in the AJAX callback. This is similar to how Ember Data handles things.
Also, `Ember.Object` has nothing to do with ORM. Ember Data addresses this with `DS.Model`.
If there's a specific case you feel like we've missed in the guides, we'd love to have you file an issue about it at https://github.com/emberjs/website/issues.