We Keep Coding

Building Real World AngularJS apps, how should I declare my controllers in html. Do I need to declare all in the index.html?

I have an application based on e.g. the Northwind database, in which I have built views for each of the different objects to maintain them CRUD-ly, using AngularJS views and the in typical file structure adopted by most devs.
I have an issue I would like to improve, firstly from all examples I have seen, you need to declare your controller on an index.html file. If one module that a user uses does not require, all the other controllers, is it necessary to load all controllers on the client side. Is there a better way to only declare controllers that are need per view?
Is this the normal behaivor of a Single Page LOB, to preload all necessary dependencies, whether required or not?

No. Don't declare your controllers in your HTML.
The less logic you add in your template, the more flexible your app will be.
The problem with including controllers in your HTML is that if some nested controllers have the same instance var (example foobar), then you don't know which one would be displayed :
<div ng-controller="firstController">
...
<div ng-controller="secondController">
...
{foobar}
Then, the best way is to work with modules and routes. With routes, you can tell AngularJS that your HTML should be controlled by aController.
I you are looking for a good app to start with, take a look at this one.
It has been developped by the AnguarJS team and shows some good practices to follow. You can notice that none of the HTML files contain a reference to a controller.

Marionette - triggering actions from controllers

I'm trying to understand all the logic behind routers and controllers in Marionette. As you can see below each example is using different approach to handle the triggering actions mechanism,so it's really hard to decide which approach should I be using.
example - link - this one renders the views from the APpController
example - link - uses Marionette.EventAggregator
example - link - uses the App instance to trigger all the actions.
It's also worth mentioning that most of them are 2-3 years old hence I'm asking my self whether or not use them in my app.
I have created a basic Marionette.AppRouter and Marionette.Controller inside my Marionette.Application instance. All the defined routes in my AppRouter module are working correctly. So I wanted to go further and update one of my views once the "#home" route is fired. But I was unable to do so, as after reading all the docs, it was still not clear to me how to update all my views from the AppController?
Should I use EventAggregator for all the communication between AppController and Marionette.Applicaiton ?
Should I define my LayoutView including ItemViews..etc in my AppController ?
Or should I just pass an instance of my App to AppController?
I' would be really glad if someone pointed me to a simple, up-to-date (AMD) example.

The newest way is Backbone.Radio. It will be the default event manager in the next big version of Marionette. You can shim it into the latest version and use it today.
Personally I decided on using Radio together with a custom made router. There are conflicting opinions on how to organize everything but I kept both radio and the router outside of the scope of Marionette.Application (window.radio, window.router, window.app). It works well and can be another viable option.

How to create route-less substates in an ember.js 1.6.x

I would like to create something like an admin sub-application that is available on every page of my existing ember 1.6.x app. It will have it's own state-machine (router) allowing it to load different controllers/templates depending on it's own state. I have seen a lot of similar discussions that revolve around having multiple state machines (routers) or extensive use of sub-routes but nothing really hit's the nail on the head.
Is there a clear way to create what is in effect two ember apps on the same page?
The sub-app does not need to actually have routes that are interpreted in the url bar. It also does not need to have it's state maintained when the parent app changes routes/states. It can be reset every time the parent app changes to a different route. What I want to avoid is repeating the same code over and over again inside multiple controllers in the parent app. I would also like to avoid polluting the application or global levels.
Below is a list of discussions that I have looked into. The closest thing that I can find that makes sense is the work on ember flows (which has not been finished yet). Or should I literally be looking into creating a new state-machine via the ember-states plugin for the sub-app?
To be clear I am not looking for someone to write the code for me. Just a discussion on how this SHOULD be done with ember 1.6.x as it is currently available.
http://discuss.emberjs.com/t/route-less-substates/2269
http://discuss.emberjs.com/t/is-there-a-reason-we-can-not-have-nested-routes/1845
Sending action to Ember.StateManager : is goToState mandatory?
https://github.com/emberjs/ember.js/issues/406
https://github.com/emberjs/ember.js/issues/4767
http://discuss.emberjs.com/t/concurrent-states-in-ember/5042
https://github.com/nathanhammond/ember-flows-generator
https://github.com/emberjs/ember.js/issues/406#issuecomment-3702356

You can run multiple embedded isolated Ember apps inside another Ember app.
An embedded Ember app can manipulate URL state like any other app or you can configure it to have routing states but not interact with URL.
Take a look at embedding applications documentation.
Excerpt:
App = Ember.Application.create({
rootElement: '#app'
});
App.Router = Ember.Router.extend({
location: 'none' // To disable manipulating URL
});
You can also share code between apps. For example to share an Ember Data model.
var MainApp = Ember.Application.create({});
var AdminApp = Ember.Application.create({rootElement: '#admin-container'});
AdminApp.Router = Ember.Router.extend({location: 'none'});
MainApp.User = DS.Model.extend({});
AdminApp.User = MainApp.User;

This could be what you are looking for:
https://github.com/tildeio/conductor.js

I guess you can use query-params i did not get your use case completely but checkout this http://instructure.github.io/ic-tabs/query-params.html#/?country=2&food=2

Ember.js: How do I associate my component with a model?

I am new to Ember.js and am trying to figure out how to piece things together at this point. One component I built, since I need a re-usable "widget" to use across many portions of my application, is a "site nav" widget. Basically, it's almost like the buttons/links you see in StackOverflow when you open a new question titled: "Questions Tags Users Badges Unanswered". In my app, these links have a name and id associated with them on the server-side. I want to be able to use this navigation widget on multiple parts of my app and it should be as simple as putting:
{{site-nav}}
into a template. I got that part working just fine, but the navigation is currently hard coded in handlebars. My question is, for a component, where is the right place to retrieve/populate model data from the server? For a controller, we do it directly from the controller's route definition. The component is not associated with a router. In fact, it can be re-used, as mentioned before, in several parts of the app.
I want to be able to drop this component into templates and have it populated with modeled nav from the server which has the name/IDs of the navigation I need. Where is the best place to do this? I'm guessing I'll still extend from something like DS.Model, but I'm not entirely sure where/when/how to integrate this with the component. When do I create the model and invoke a .find() type call to the server to populate site-nav with data?

you can pass value to component Passing properties to component
via handlebars.
{{my-nav navlist=listfromserver}}
so the list from server is in our controller can be passed to the component

Does Angular JS support routing of multiple views on the same page

Does Angular JS support having multiple ng-view sections each with its own templates on the same page? When setting up its configuration you need to wire up the different url path to different controllers and templates. But when you have multiple views on the same page, then they will each need to adjust their template and controller using the #path value from the url, and to change the view template we'll be need to switch as the #path value changes.
So how would the different ng-view sections play with each other - as each would need to append its own unique #path value to the url. Or is the url path and #value somehow kept as a private construct within each ng-view and therefore allowing multiple ng-view sections on the same page.

Multiple views is a limitation in angularjs and the documentation does not make it clear how to structure an application with complex views properly. Please have a look at Jan Varwig's posts on this topic
How to do nested views in AngularJS (Hint: Don’t)
AngularJS: Views vs. Directives
Relevant Sections:
"Views are not what you use to structure your application!
In fact, views are more of a crutch, a shortcut, to create structures similar to traditional websites, only with angular as a driver. When developing a web application, the way to deal with complex interfaces is to use, in combination:
Scope objects/variables that store your desired view state explicitly
ngSwitch directives on this view state
Directives to include custom templates/perform complex DOM manipulation behavior
Stop thinking of your application in terms of views that need to be loaded. That kind of thinking aligns better with imperative frameworks but doesn't work well in angular."
"View-Containers are meaningless, separated from their semantics through the routes.
The other, secondary gripe that I have with UI-Routers nested views is that they violate another core idea of AngularJS: Your DOM is the main place to describe the structure of your app. Reading a template should give you an idea of what goes where. If you want to edit a user, put a directive into your template:
A reader will immediately see what that directive does and what data it depends on.
If you write the directive correctly it will be location independent, you can place it somewhere else in your app, as long as you pass in a user through the attribute it will work.
Using views litters you templates with meaningless containers, outsourcing the actual purpose of every view into the routes/states defined elsewhere. If you nest routes, the context of every view becomes implicit, it is harder to move them around and the only way to pass data into a view is through the scope."

ng-route does not support multiple ng-view inside ng-app.
You can take a look at ui-router as a project which provides some support for having multiple layouts (including nested layouts) tied to the URL.
Caveat Emptor
Note: UI-Router is under active development. As such, while this
library is well-tested, the API may change. Consider using it in
production applications only if you're comfortable following a
changelog and updating your usage accordingly.

Use ui-router instead of the canned ng-route! ui-router totally has nested views, and its awesome and really easy to learn. I would reccomend using ui-router instead of ngRoute to anyone.

Having done further reading on this, it appears that although functionality for multiple ng-view has had number of requests it was not able to make it into the Angular release, but there is possibility of something in future releases.
In this discussion Misko Hevery pointed out another approach, which is to use ng-include.
Then there is also the custom directive approach in Jan Varwig's posts which Vikas has already cited.
Also found this Angular Multiple View project on github which can be a further approach.

For this sort of thing you can use templates.
Create a file e.g. firstNavigation.html which has your snippet of html. Then call it in the controller like so.
$scope.nav = 'src/partials/firstNavigation.html';