"This commit introduces the notion of "private" properties (properties whose names begin and/or end with an underscore) on the scope chain. These properties will not be available to Angular expressions."
I wish they'd discuss stuff like this and I wish that MongoDB did not store primary keys on _id field.
It is also clear from the discussion that there are dissenting opinions -- we are constantly iterating and welcome issues and pull requests to make features work even better. The best way to influence AngularJS is to send a pull request.
You are right it was. But most people do not track all issues of all projects they depend on. While I'd love to do that, there's simply not much time.
I belive this should have been in an earlier RC or Beta. This way, more people would have tested ot, ir got a chance to read changelog (I follow the blog and check each beta release). If that window was missed, it should have gone for the next major release.
Many other languages and projects use underscores to indicate private properties, in particular Google's Closure. I also have no idea how standardizing on _ in names meaning private would do anything to push Dart in some hidden, evil agenda.
I think the change is reasonable, limiting AngularJS' expression to leak less information into the templates is a good idea IMHO, as described in particular with the new controller syntax.
Disclosure: I work at Google, but I have not been involved in this discussion at all.
I pay pretty close attention to the issues in the repo, but I apparently missed this. I am also a regular in #angularjs, and never seen it discussed there either, so while the discussion was public, I think it caught almost everyone by surprise.
I'm running into a similar issue and fairly new to angular. In fact, the tutorial I followed even set up the server calls to use the _id field when looking at a specific model (ie leagues/{{ league._id }} ). What's the proper way to go about fixing this?
so what the point of introducing a "private" access modifier that doesnt exist in javascript since one can still access privates? looks like pure politics within google.
A breaking change like that shoved at the latest minute? you bet it is.
why didnt you think about having this feature optional? class based controllers are optional yet,because of them you introduce a feature that affect function based controllers ?
Never send DB output directly to frontend, send object, filled by only necessary values from DB output. Otherwise you'll meet security issues and these "_" prefixes will be smalles part of your problems.
I've previously worked with Backbone.js, and found that many things in Backbone where I've had to manually develop are readily available in Angular.
Moving from Backbone to Angular has made the code much cleaner, and smaller in size. Whereas in Backbone, the code slowly became a mess with all the event listening and event triggering (probably my fault), in Angular, that has all been abstracted for the most part.
We've been steadily working on improving the docs, and rolling out significantly improvements on a regular basis. Is there any particular part of the docs that still ails you?
I've done one project with ember and was very happy with it but I'm now working on a project where I only need parts of the page to be controlled by the framework. So far I'm loving the way angular integrates with the dom but once you get back to the controllers/directives it suddenly feels like I have to do a whole lot more work than with ember. The main difference seems to be that you have to manage updates yourself i.e. use $watch or trigger them yourself by binding to js event. At this point I'm kind of wishing their was an embular project ( :) ) that integrated with the dom the way angular does but had ember's awesome binding/computed properties...
Can you give an example of where you've had to use $watch? Usually too many $watch is an indication that you could improve your app's architecture, e.g. by abstracting into directives.
FWIW I'm only speaking from personal experience and in your case lots of $watch might be necessary.
A good example is where I have a list of items which is filtered by a select[1]. I have the select wired up to the controller with a two-way binding and the controller watches for changes to the binding and filters the list accordingly. Maybe this isn't an idiomatic way to do it?
Ah, so I see that anything associated to the scope is reavaluated whenever anything else in the scope changes. Here's a further modification based on yours that keeps the criteria on the controller.
I haven't had to use $watch except to integrate with jQuery plugins for fancy widgets (and wish I could get rid of those). For everything else, two-way binding in Angular works very well.
I've actually just inherited a giant mess of knockoutthat i was looking to replace with angular. I have to admit that I was actually expecting angular to handle this kind of stuff so I'm a little disappointed in that respect. Angular does seem to have plenty of benefits but I thin i'll give knockout a full review before(maybe it just needs to be structured better).
I was expecting a) a blog post, and b) from the .html-ending a hypertext document, maybe with text and images?
What possible reason could there be for this to be "an app"? It's a blog, it's for reading -- and you already need a reader to access it -- why would you implement a (new) rendering engine?
Ok, I can see an argument for adding comments via javascript and a service, or for posting blog posts and doing admin stuff. But the other reasons (user tracking etc) for having this as "an app" only detracts from the readers experience.
Well, if they just served html, they'd still only need to serve the content (and the viewer, the web browser, would indeed be cached in the form of an installed application on the end user's system).
The content can be served as a JSON object containing just the post and the metadata. If you scale up to millions of requests, suddenly you're saving a lot of bandwidth by not sending the same header, sidebar, footer etc everytime.
1) You could send the sidebar, footer etc as json, and the content as html. [edit: an by json I mean javascript ;-) or a combination of a script-tag with a fancy-nav.js, and then pull in any additional elements via json/javascript urls]
2) "lot of bandwidth" - I doubt it. It's only the embedded html you'd have to resend -- and that gets compressed with the rest of the main html document. Everything else (images, css, javascript) gets cached via normal request caching.
Well, I just figured out that these "blogs" (edit: blogger.com blogs) at least provide rss -- doesn't really work in w3m (it downloads the xml, rather than doing som magic and try to render it) -- but at least for me this "design" is far superior to the bloated javascript mess that they try to get you to use:
We've been using rc versions in production code too. As they've mentioned many times when they say unstable it doesn't mean that it was likely to break, simply that they are free to change the API if they need too.
Does anyone know what's the rationale behind the separation of ngRoute? It's less than 4KB and less than 2KB when gzipped. I don't think it's worth the "pain" of having to remember to add another source file.
They want to split in lot of optional modules, it's just the beginning. IMO it's a good idea. For your problem, perhaps they should add a custom build/download tool like jQueryUI.
I think it's a great idea as well. Would like to see jqLite come out as well and be a separate project. Then those using jquery don't pay for jqLite, and even beter, for a quick landing page I'd be inclined to use jqLite naked for a nice tiny footprint.
what is your build process? (angular noob here)but I would assume your dependency resolution takes care of this.
(this sounds to me like build vs real issue)
Great timing. The angular based project I've been working on for the past 6 months just had a soft launch the other day. Being able to tell the powers that be that we are no longer on the unstable branch will ease a few minds.
Nice guys! I've been tracking the rc's with Ionic Framework (http://ionicframework.com/) and just updated to the final. I've especially loved ngAnimate and ngTouch which have been really solid.
I noticed that Angular was likely to release this morning since all the issues for the milestone was finally cleared out - looking forward to moving to 1.2 stable from 1.2 rc2 (we're using rc2 in production code!).
Also looking forward to seeing new Angular features being worked on again!
Take a look at the pull request queue on Github. We've been focused on 1.2. There are a lot of new features and proposals that we'll pick up now that the release is out the door.
I wish they'd discuss stuff like this and I wish that MongoDB did not store primary keys on _id field.
I blame myself though.