Develop Reference

best practice controller / services

I have built an Angular app that consumes data from different sources (SharePoint lists). I setup a controller for each source.
What is the best practice for this? Use only one controller for the app and different services? Or one service and one controller? Or multiple services and controllers?
In the app I do not use routing.

First I'd recommend reading these articles. Also, go through their angular implementation and see how they've achieved some of their effects. It will throw you in a world of problems that you'll feel like "Why? I mean, why? why did I ever got into this mess?" But, grit your teeth and get through it. Then you'll see how much you can achieve. Learning Angular JS is a never-ending cycle of this.
angularjs-best-practices-directory-structure
Angular Style Guide
Advanced Design Patterns and Best Practices
The Top 10 Mistakes AngularJS Developers Make
Ok, and to answer your question: your way isn't wrong.
But controllers are not designed to be used like that. Controllers are a unit of code which co-ordinates your data into the UI, handle UI events, etc. generally of a certain view - i.e. a portion of your UI (navigation bar, home page, edit form, etc.). Of course this can be your entire page as well. But it's best to break it down so that it's easier to manage.
Use services for what you described. Create a service for each data source or type of data (users, equipment, roles, etc.). I recommend that latter, since sometimes you need to pull data from multiple ends and tie them together. This can be done inside your controller as well, but having services will enable you to re-use that functionality in another part of your application.
To summarize a long answer, I'd say go through these articles, code and tips. Then build a structure that will help build your application. Just don't over-engineer it.

I would say: use a controller for every "piece" of HTML in your app, (and it depends on the scale of your app how big that piece is, it could be just one controller if your app is really small). And use a service for each data source. Then you can use the services your need in your controllers. You could also use one service if you don't need a lot of behavior. It all depends on how big your application will be.

Something Similar To ASP.net User Controls for Javascript Web App Development?

I'm assigned to work on a Javascript solution that seems fairly easy to implement in platforms like ASP.net, WPF, or Flash Builder (because I can create separate components and controls).
The project requires many types of file selection-like mechanisms for each unique type of related data, many of each require auto-completion-like capabilities, navigating a file hierarchy-like system, and pagination. There are also multiple tabs for managing the different related pieces of data of the complex object.
Also, the user must be able to save and retrieve work all on the same page.
Such a requirement requires tons of markup and event-handling code in one page, which easily results in over 1000+ lines of code, even with jQuery and knockout.js. (It becomes very tedious to wade through and maintain.) Is there a way to create separate "pages" with both HTML and JavaScript, and then embed/reference them on the main HTML page?
Is such a project with such complex requirements better suited for Flash Builder or Silverlight, or should we stick to Javascript & HTML?

It looks like you're building a Single Page Application.
I'd recommend looking into AngularJS. It allows you to include HTML templates and bind controllers to them.

I strongly recommend YUI3
YUI3 contains many features and widgets like calendar,auto-complete,many types of data-table(grid),template rendering, Ajax call(sync & Async), event handlers, Panel , accordation , TabView, Router and etc...
have a look at below url.
YUI3

Real world webapp structure with Spine.js

I've been diving into JavaScript MVC for quite a while using Spine.js and CoffeeScript. I develop Ruby on Rails since a while so I understand what the models, the views and the controller should handle respectively (based on my moderate experience with it). But in Rails we already know that (generally speaking) each controller is basically something that controls a bunch of views (or pages) and deals with one or more Models at a time. (Maybe, so correct me if I'm wrong as I'm not a pro yet I have to confess).
However I found a whole different concept with Spine in terms of architecture. I read its documentation and dove into its sample apps. Unfortunately all the Spine sample apps are showing how to deal with a single page app, something that in a real world "larger" application would not be the case anymore. (Correct me if Spine should only be used for "single page apps").
Assume there is a website (or app) that consists of many pages/sections/modules as follows:
1 - A home page, displaying for example, a thumbnails based list
2 - A contact page
3 - A profile management page for the current user (normal CRUD)
Each page has the same main structure (or layout) as in a header with links to the above pages, a search input field and a log out link (I already know the log in page should be separate, so I won't ask about authentication in here).
The tricky part here is I can't really figure out how to tie the whole parts together and I've been asking myself some questions, searched on Google and StackOverflow but without clear answers.
1 - "Must" a spine app application be in one page only? I mean, having header and footer fixed but with a dynamic content DIV which loads and unloads views based on which tab the user clicks on the header? Or should I treat each page as a standalone spine app?
2 - Do I have multiple controllers in one page? For example, the app main controller and navigation controller (header)?
3 - Is it true that each controller should be dealing with one Model, or the one associated with it? (In the samples there was always a 1 to 1 relationship between them, like Task Model and Tasks Controller).
4 - Where should I store interface related state variables in my app. Should I create a model that "remembers" the current user, or for example which tab is highlighted for further reference? Or should I store them into the controller(s)?
5 - If it's going to be a single page app (but with many sections or modules), should I have a controller for each loaded section inside of this page?
I know these might be trivial questions for more experienced programmers but I really don't know where to start. So it would be awesome if someone could guides me to the right track.
Thanks in advance!
DD

I think that this is a very good question. My answer will be quite broad, so bear with me.
The essence of my answer is that you need to get familiar with other frameworks in order to understand what the one you chose is trying to solve. Your problems are understandable. Other people have struggled with lack of one "proper" way of doing some common things. Solutions were created in terms of examples, wrappers/extensions and alternative frameworks. Perhaps, you should seeks information related to Backbone, which inspired Spine and is still similar to it.
As you said, you're familiar with Rails' MVC. And then comes Spine's MVC approach and it is totally different. This should give you a hint that MVC (or MV* in general) is broad idea that has very different implementations. OK, you might be thinking that Rails is a request-based server-side framework after all and that Spine is a client-side event-based framework - so the difference is understandable. Well, there is no uniformity amongst client-side JavaScript frameworks either. For example, the mentioned Backbone has so-called Views, which actually play the role of controllers. So I guess that one thing that Spine's creator did was renaming Views to Controllers for clarity. MV* for JavaScript is explained in detail by Addy Osmani. There is also a good overview of JavaScript frameworks.
So one "problem" with Spine and Backbone is that they do not dictate any architecture. In other words, they are not opinionated enough. You can use them as your want and this fact makes frustration. Below I try to answers your questions:
With Spine, application is not required to be a single-page application (SPA).
You may create an app that has multiple pages, each loading it's own Controller. In this case, your views can be rendered on server and your models can be bootstraped from generated JavaScript. This is good when you don't want a SPA, but still would like to organize JavaScript or have some reusable components.
However, judging from the feature set of Spine (e.g. routes), it was created with SPA in mind.
For SPAs and complex UIs in general it is good to have parts of UI (widgets) separated. In Spine, Controllers are the means of such separation. So yes, use multiple controllers and use controller nesting. Perhaps, there should be a topmost application controller.
That's not true (no technical limitation), although single responsibility principle makes things easier.
Store those variables in the controller of corresponding level. Store them is models if you need to observe those values, otherwise store them as controller properties.
You can have an App controller, that holds a header, footer, sidebar controller and an active page. In Routes, you create a corresponding controller and pass it to App controller, which replaces the main area content with the element of that controller. This is one possible approach.
Once again:
People have struggled with lack of concreteness in terms of application architecture in Backbone/Spine. They have created some solutions like application controllers, layout managers and so on. For Backbone, you can take a look at Marionette, Chaplin or Thorax. By learning from them you will be able to come up with an architecture for your Spine application. Good luck!

Best way to structure a multiple page application in Javascript

As an Actionscript programmer shifting to JS/jQuery I often have to author multipage apps targeted mainly to iOS and I'd like to know what is the best way to structure such apps.
Most of the time my apps are presentations, where each page has a different behavior (i.e., some popups on page1, a group of sliders on page2, some drag and drop action on page3... you get the picture), and more often than not I have to keep track of several variables across different pages.
Right now I handle it like this: I have a group of common functions in a script named my_app.js, while each page has its dedicated pageX.js script to account for its specific duties. I store persistent values through the storage.js library and somehow manage to stick it all together and make it work.
However I recognize that there may be a vast area for improvement to this approach, so I'd like to know how more seasoned developers deal with this situation.
Thanks a lot,
Goblin

What you've done seems OK for a smallish app, but as another answerer said, I'd look at an MVC architecture. I can heartily recommend backbone.js, it's pretty lightweight, and simple to use.
You could easily make a controller for each type of view that you need (e.g. sliderController, dragDropController, etc) and then if you needed to, subclass ('extend') these controllers to be platform specific (e.g. iPhoneSliderController, iPadSliderController, desktopSliderController, etc).
If I had more info about this app - like the data behind it, what the user is achieving by dragging/sliding - then I might be able to give a more specific layout for the models, views, and controllers you might want. But hopefully this is a good starting point, and if you take a look at the backbone.js documentation, it should give you a good idea if it's appropriate for your app.

The structure you have sounds sensible enough (common JS file complemented by page-specific JS files). It also sounds like you're onto the right lines with storage.
What I would do in your situation is focus on how your code is structured in terms of architecture. Chapter 6 of Stoyan Stefanov's Javascript Patterns (O'Reilly) would probably be quite enlightening.
I would also probably explore JS MVC implementations given your situation would lend itself well to this methodology (lots of views).
I realise this is only scattered thoughts, but hopefully it might give you some ideas.

Here is how I organize stuff
in /
modFOO.php
modBAR.php
in /js/
main.js
resourceloader.php //this is a resource loader, so I can load multiple JS in a single request
in /js/pages
modFOO.js
modBAR.js //javascript that for page modBAR
in /css/
main.css
resourceloadercss.php //this a resource loader, so I can load multiple CSS in a single request
in /css/pages/
modFOO.css
modBAR.css
With this setup I know exactly where to find stuff, and where to put stuff. And based on the filename, modepic.css, I know exactly where to put the file, and what is (the CSS file for modepic).

Is Backbone.js only for single page applications?

I'm searching for a simple architecture for my UI that will have some basic javascript functions in like: select all checkbox's, image crop, some pop-ups and some other plugins.
I found this article: Organizing Your Backbone.js Application With Modules
My application is not a SPA (Single Page Application). I want to know if Backbone.js with jQuery will help me even if my application is not a SPA.

The strength of Backbone is really in its ability to manage many models (even complex ones) and keep the rendered page in sync with their current values. It provides an interface to getter/setter functions so that the changing of a model value (there are many different flavors of "change") will call render on the corresponding view and the page will correctly reflect the underlying models. Furthermore, it provides interfaces to saving, paging, and routing actions on models.
I have used Backbone extensively for both SPA's (where it shines) as well as more traditional, multiple page applications. It has no special support for UI and DOM manipulation, but combined with jQuery/Prototype/Zepto it manages their rendering/manipulation.
Basically, backbone works best to untangle elaborate chains of rendering logic and model updating. If you feel that your application has a lot of view elements that need to stay in sync with models that the client will be updating on the page, Backbone is a wonderful solution. If you just need to select and manipulate DOM elements, it's overkill. jQuery alone can handle that.

Backbone is really not about the things you mentioned, but I wouldn't say it is strictly for single-age apps (SPA) either. I'd say it is for any case where you've got quite complicated pages and it would benefit you to break them up into multiple pieces (for example, several views that all pull data from one model).
However, I would say the strength of Backbone.js is in the SPA realm.
You could probably find some jQuery pieces that answer some of your needs if you're not already using jQuery as part of your app. However, jQuery is all about the parts you mentioned (easy DOM manipulation, popups if you use jQuery UI, etc.) and not about structure or organization.

I believe that the principal idea of backbone, is organize you JS code in complex app using the MVC concept.
This way your app becomes easier to mantain and add new features, It get easy to use frameworks tests like jasmine.
Backbone also make possible (and very good) work based on SPA approach, using ajax request to server. It is completely based on Restful concept, to get a code using backbone, is important to understand what is Restful.
Basically Backbone have a Router (that can work like a controller. but is not a controller).
Model that is where you can manage all the data logic of your application.
Collection that is like a list of models.
View that is where you will react accordingly the model changes.
There are other things, but basically, is this.
But as I said before, you can use it without have a SPA.
The most important thing to have in mind is that the concept of MVC must be followed when using backbone. If you don't do that, it doesn't make sense use backbone.