not satisfied. How about lazy-loading and plug-in-able architecture, Large applications require so many modules and most of the time, users only use 10% of the features, why load everything everytime?
IMHO, I would say that this presentiation is more like "Writing Angular App that is not a simple Tutorial", since any mid-sized application must have (1) a way to share features between controllers and (2) wraps REST API in logical objects (see Restangular for that). Must say the stuff to rip off UI features based on user authorization is very smart, but not related to "Massive Apps"
re: Code Organisation I'm struggling to see why services aren't just used in every case. I must be missing something, or maybe when this presentation was given angular services/factories/providers worked very differently to how they do now.
really don't like the 'helper controller' implementation, you are creating a dependency on them in the 'actual' controller but it's not 'visible' as a dependency as you are instantiating them inside the 'actual' controller..looks a lot like using Angular's DI as a ServiceProvider (something of an anti-pattern as it hides the presence of these dependencies) .. still some interesting things to think about though
Regarding the first section of this talk about authentication I thought the part about authenticating on the server side was an interesting idea. But it seems to me that hiding html using the data-keep and data-omit attributes on the client side would be quite vulnerable to attack. Is this the case or am I missing something?
Most companies authenticate views because it is a faster solution but these guys authenticating functionality because their directives and controllers doesn't know what to do with the 402 response. If the views has anything static that unauthorized user shouldn't see that's a problem because they can see it very easily on the other hand this is against the nature of angularjs because angularjs is very strong in data binding and we bind models to views and templates. So if you authenticate the data requested on the backend there will be nothing to see except empty templates if they try to hack it.
I'm sure they do ACL and validation on the server side too, as that's the only way to really enforce these things. Validation on the client side is just presentation for the user.
Very interresting (especially the first talk) but I wonder one thing : if we inject the user profile in the html (previously done by a post login response), how you transfer an api key ? In the html too ?
Another comment. I don't think the use of "$controller" is appropriate. You should instead use '$injector.instantiate()". It does the same thing, but it does not confuse object creation with controller creation. Although I admit it is longer to type...
I was planning on implementing a solution like the one they use for authorization where you embed application context in the index, and redirect to login page when you are logged in, but I ran into the situation of a link into my application. I would want this link to force log in and then go to this link. Since my application is using the hash instead of HTML 5 history fanciness I couldn't do this and was forced to abandon this approach. It made me sad...
Will Seitz Note that I found a solution combining checking the Url-referrer in the header combined with the basic history API, but that is pretty kludgy.
I have to come here to say the is impossible to build a massive angular app. I'm being doing my second app, with a lot of controllers. And is horrible. I'm trying to leave this software and begin a brand new mvc-classic style because it works pretty well. My issues are, horrible to: test, validation on field, to a proper mock, paginations/order by (this rely most on server side of course). Impossible to load file on demand on sane way. Angular is not ready yet for large project, it can be "good" for some component (calendar?, todo-task? hello-world?) I regret using it. I should give a try on ember.
Of course, a team of 20+ highly skilled js engineers from Google must be completely wrong, they don't know what they're doing and they don't realise angular is not ready for a big project.
Let's see what you can do then, for sure you are a great speaker and you've been invited to world-class conferences to talk about your work. They are not actors, they are engineers. The video is very interesting, if you want to be entertained I suggest to watch something else instead.
Don't be stupid, I don't need to be a great speaker so I can dislike a speech as you don't need to be a great filmmaker to dislike a movie. And yes, they just read their slides, it's a fact. If you think this is good, good for you, I don't have to like it just because you do.
Mauricio Almeida I totally agree with you. I am just a village coder but I can see this world-class video doesn't give me any good hints, solution for huuuuge/massiv/large application. I think they should focus more on lazy-loading and plug-in-able architecture, Since large application require so many modules and most of the time, users only use 10% of the features, why load everything everytime
This would have the same performance hit as ng-show or ng-hide. It does remove the HTML snippets from the DOM, but during every digest cycle it will have to reevaluate all of the bindings on that template.
For Authorization, assuming your login page is loaded from your index.html you won't have your user info yet because you don't know what user is going to log in. I love the idea but I don't understand how they are rendering index.html and injecting the active user profile into the page before any user actually logs in. I'm thinking maybe they don't load index.html until after the user logs in? But then that means no angular on your login page. I think I will implement a similar system using custom attributes and the http intercepter, but I will extend my ApplicationOauthProvider to return the user and role information. By the way the link for the Authorization code they present is gist.github.com/idosela/8421332
Some very useful concepts - using interceptors, code organization (composition/services), and data transformation.
not satisfied. How about lazy-loading and plug-in-able architecture, Large applications require so many modules and most of the time, users only use 10% of the features, why load everything everytime?
Wow that was fast. Already posting the videos! Thanks!
IMHO, I would say that this presentiation is more like "Writing Angular App that is not a simple Tutorial", since any mid-sized application must have (1) a way to share features between controllers and (2) wraps REST API in logical objects (see Restangular for that).
Must say the stuff to rip off UI features based on user authorization is very smart, but not related to "Massive Apps"
re: Code Organisation
I'm struggling to see why services aren't just used in every case. I must be missing something, or maybe when this presentation was given angular services/factories/providers worked very differently to how they do now.
Any plans to publish the "apiProvider" code? e.g. apiProvider.endpoint('songs').
read my mind..
Good stuff. IMO first part the best.
really don't like the 'helper controller' implementation, you are creating a dependency on them in the 'actual' controller but it's not 'visible' as a dependency as you are instantiating them inside the 'actual' controller..looks a lot like using Angular's DI as a ServiceProvider (something of an anti-pattern as it hides the presence of these dependencies) .. still some interesting things to think about though
Regarding the first section of this talk about authentication I thought the part about authenticating on the server side was an interesting idea. But it seems to me that hiding html using the data-keep and data-omit attributes on the client side would be quite vulnerable to attack. Is this the case or am I missing something?
Most companies authenticate views because it is a faster solution but these guys authenticating functionality because their directives and controllers doesn't know what to do with the 402 response. If the views has anything static that unauthorized user shouldn't see that's a problem because they can see it very easily on the other hand this is against the nature of angularjs because angularjs is very strong in data binding and we bind models to views and templates. So if you authenticate the data requested on the backend there will be nothing to see except empty templates if they try to hack it.
I'm sure they do ACL and validation on the server side too, as that's the only way to really enforce these things. Validation on the client side is just presentation for the user.
Very interresting (especially the first talk) but I wonder one thing : if we inject the user profile in the html (previously done by a post login response), how you transfer an api key ? In the html too ?
Probably cookies.
bruno c Could also be kept within the user profile... The page is rendered on server side, so no problem.
Another comment. I don't think the use of "$controller" is appropriate. You should instead use '$injector.instantiate()". It does the same thing, but it does not confuse object creation with controller creation. Although I admit it is longer to type...
Wow, that's a great talk, guys! :) You made my morning :)
ce vdo est super lol! c Yacine la cadette
Very interesting and instructive.
I was planning on implementing a solution like the one they use for authorization where you embed application context in the index, and redirect to login page when you are logged in, but I ran into the situation of a link into my application. I would want this link to force log in and then go to this link. Since my application is using the hash instead of HTML 5 history fanciness I couldn't do this and was forced to abandon this approach. It made me sad...
Will Seitz Note that I found a solution combining checking the Url-referrer in the header combined with the basic history API, but that is pretty kludgy.
I have to come here to say the is impossible to build a massive angular app. I'm being doing my second app, with a lot of controllers. And is horrible. I'm trying to leave this software and begin a brand new mvc-classic style because it works pretty well.
My issues are, horrible to: test, validation on field, to a proper mock, paginations/order by (this rely most on server side of course). Impossible to load file on demand on sane way.
Angular is not ready yet for large project, it can be "good" for some component (calendar?, todo-task? hello-world?)
I regret using it. I should give a try on ember.
Of course, a team of 20+ highly skilled js engineers from Google must be completely wrong, they don't know what they're doing and they don't realise angular is not ready for a big project.
Fabio Sussetto They are. Perhaps angular 2.0 will be great, but no 1.xx. Did you do any full-app before comment? I did it.
The speakers just read their full-text slides out loud. I don't need a video for this, just a link to their slides or a book.
Let's see what you can do then, for sure you are a great speaker and you've been invited to world-class conferences to talk about your work. They are not actors, they are engineers. The video is very interesting, if you want to be entertained I suggest to watch something else instead.
Don't be stupid, I don't need to be a great speaker so I can dislike a speech as you don't need to be a great filmmaker to dislike a movie. And yes, they just read their slides, it's a fact. If you think this is good, good for you, I don't have to like it just because you do.
Mauricio Almeida I totally agree with you. I am just a village coder but I can see this world-class video doesn't give me any good hints, solution for huuuuge/massiv/large application.
I think they should focus more on lazy-loading and plug-in-able architecture, Since large application require so many modules and most of the time, users only use 10% of the features, why load everything everytime
he sounded like Leanord from the big bang theory!
Why not use ng-if instead?
This would have the same performance hit as ng-show or ng-hide. It does remove the HTML snippets from the DOM, but during every digest cycle it will have to reevaluate all of the bindings on that template.
Frank Shaw True
***** Interesting!
For Authorization, assuming your login page is loaded from your index.html you won't have your user info yet because you don't know what user is going to log in. I love the idea but I don't understand how they are rendering index.html and injecting the active user profile into the page before any user actually logs in. I'm thinking maybe they don't load index.html until after the user logs in? But then that means no angular on your login page.
I think I will implement a similar system using custom attributes and the http intercepter, but I will extend my ApplicationOauthProvider to return the user and role information.
By the way the link for the Authorization code they present is gist.github.com/idosela/8421332
Love the way presenters rush through their examples!! ridiculous lol