I always wonder
How Sencha Touch 2 knows which controller to run first and which one is the next
How does ST2 knows which controller is in charge of which view.
Can we have more than one controller on one view, if yes, how to wire them up?
Can we have more than one views controlled by one controller? if yes, how does the events flow?
How to wire up view1 with controller1,......, viewX with controllerX.
Thank you.
Re.: 1 - Controllers are initialized, if you mean that by "run", in the order they are listed in application controllers:[] array. See also ext application startup sequence:
Re.: 2 - Controllers just listen to events that come from views. The listeners are installed in init method of controller
Re.: 3 technically yes - more than one controller can listen to events of same view - but it is not a good practice. It's like to have more bosses
Re.: 4 yes and it is ver common that one controllers controls more than one view
Re.: 5 see application architecture
My answer refers to Sencha Touch 2.3.1.
There is no real "coupling", except the relations you define through refs and control property of the controllers http://docs.sencha.com/touch/2.3.1/#!/api/Ext.app.Controller.
All of the Controllers that an Application uses are specified in the Application's Ext.app.Application.controllers config. The Application automatically instantiates each Controller and keeps references to each
I guess the order in which the controllers are included is defined by the controllers property of app.js (it would be pretty easy to verify anyway by putting some console.log() in the init method of each controller).
There is no such a relation of "being in charge" for a View, controllers have references to Views, that is all. It's worth mentioning that controllers may require views (and stores and models) but that is just related to inclusion in the packaging phase, there are no "bindings" to those components at runtime.
It's possible, just define two controllers that have both a reference to the same view. That would be bad anyway, because it would spread the logic for the same view in multiple places.
Yes it's possible. For example I use to write a single controller to manage set of simple views always used together (for example a wizard). You simply have all the handlers for the events of those views in a single controller.
The encouraged way is through through refs and control property of the controller http://docs.sencha.com/touch/2.3.1/#!/api/Ext.app.Controller.
In summary, in my opinion, controllers are more a tool for the developer to organize code meaningfully and to improve maintainability, rather than a rigid implementation of MVC in the framework.
Related
I am implementing a functionality for (Add,update,delete & get,filter).
Currently Add View is used for add, update and delete. (Controller1)
Get View is used for get and filters. (Controller2)
Created routing for Add and Get Separately. So 2 controllers for each.
Now i have to call service for common config data , which is used in both the controllers.
which of the below design i should prefer.
Design 1
Combine both the controllers a one controller, put all the code inside.(including config data)
Design 2
One controller for Get ,filter
Second controller for Add, update and delete
common factory for Config data.
Am confused, which design i should prefer from all the aspects.
Please suggest.
Thanks in advance.
Its good practise to have "skinny controllers"
EDIT -
In AngularJS, controllers can sometimes become monolithic structures of mixed business and view logic, as it’s all too easy to house anything you need for the view inside the controller. It’s convenient, and it just plain works… until your application grows in complexity or needs unit tests.
So why do we want skinny controllers, anyway? In short, separation of concerns. Ideally, everything from services, to controllers, to directives, and more should be skinny, and achieving this is very possible in AngularJS. Each part should have a single responsibility and the controller’s responsibility should be to communicate between services and the view; i.e. its main concern should be view-model logic.
Aim to make your controllers skinny, as well as the rest of your application, by separating out view logic and business logic into controllers and services, respectively, and by taking advantage of routes and resolves.
You can read up in detail in this article & look at code examples
I'm new to AngularJS and i'm wondering what's a good way to visualize a AngularJS app (with UML classdiagram/componentdiagram)? And the reason why.
Can you give a example?
I found this, but don't know if this is a right way: https://hacks.mozilla.org/2014/11/visually-representing-angular-applications/
Thank you
You can use a Class Diagram to represent your Controllers, Factories, Services, etc (as show in the link provided by M22an in comments). In this diagram, you can easily show the methods and attributes of each Controller / Service / Factory.
You can use a Sequence Diagram to represent the communication between the parts of your app. Show each method, show which part of a service it calls, the data given and received, the update of the template with the $apply method etc.
A component diagram can be useful to explicit the content of each module and show the Controllers / Services / Factories... inside it. You can show the modules dependencies using this diagram too.
In my opinion, you can use almost all diagrams you want, AngularJS is huge, powerful and complex, and each UML diagram will be useful to represent a part of his behavior.
I'm currently learning ExtJs, but I can't seem to grasp my mind arround the following.
What is the difference between the array notation and the requires notation
For example:
view['MyPanel']
model['MyModel']
controller['MyController']
store['MyStore']
requires: ['namespace.view.MyPanel']
Do they do the same or ... ?
And why do I have to put ALL the views, models, controllers and stores used in the application inmediatley in the app.js?
Can someone clear those thing out to me? :)
Requires will just load the files matching the class name from the server. It will not instantiate anything. You should require what is needed in each view/controller/model, you don't need to have it all in app.js.
For instance, if you have a MyModel that has a relation to MySubModel, then MyModel would require MySubModel. Requires is essentially about loading other classes when needed so that they are fetched from the server before being used - since using a class when it is not loaded creates a noticable delay due to ExtJS having to fetch the class from the server before instantiating it.
The models, views and controllers arrays in a controller are a convinient way to require such resources as you don't have to specify the path to the models/controllers/views folders. See the docs on controller models config for example.
A guide on how to structure your application is available here even though I don't really like that they load all views and all controllers in this approach. But it's a good start. You can dynamically load stuff later on when your application grows.
So, I'm in the midst of my first major project with Angular. I have one controller that is doing a ton of the legwork, and it's reached the point where it's thousands of lines of JavaScript.
I'd like to break this up somehow, but I can't seem to find a solid example anywhere. The code is mostly made up of functions used to do calculations on objects, so directives and modules don't seem like the right answer, but I could be wrong there.
How are you guys organizing code in your large Angular projects? Should I just suck it up, or is there a sane way to split this into easy to scan files?
I suggest putting at least some of those objects and their related calculations into services, then inject the services into your controller(s). See the Sticky Notes Part 1 blog entry for an example of a service that encapsulates some data and provides methods to access/manipulate that data.
See if you can break up your controller into multiple controllers, one for each view. A view can be as large as a page, or just some chunk/block on a page.
To quote from a google group post I saw recently: "I prefer to think of angular controllers as dumb apis/configs for my views and leave all the heavy lifting to services." -- reference
There are a few things that you need to ask yourself when you are in a controller.
Are you doing any DOM manipulation in the controller? This is a definite NO. Dont ever do that. It always belongs in the directives department.
Are you writing any Business Logic in your controller? That too is a NO. Your Business logic should in most cases exist in a Service. That is the right place for it.
Now, have a look at your controller. Is it devoid of these 2 things and still larger than 1000 lines? It is highly unlikely, but even if it somehow is happening, then consider breaking down your controller into smaller controllers. This breaking of controllers have to be done based on the view.
To sum things up, your controller is just a place where you glue up the business logic and your views in the HTML. It should technically never contain anything other than these glues.
I usually create a Util factory (seems to be the way to go now in Angular rather than services) and have it return any shared logic as a set of methods.
https://gist.github.com/lamba/c275f5f010090632209e
In a Composite WPF application, what is the best way to store global variables needed by several modules? For example, I am working on an application in which several modules need to get a file name, so they can fetch the data they need from the file.
Is there a best practice for storing information like this in a Composite WPF app? How do I get the information to my modules while still keeping loose couplings? Thanks for your help
David Veeneman
Foresight Systems
Write a service that encapsulates the logic you require and package that service into a module. Then have your other modules use that service to get their job done. Note that the service may expose the file name directly, or may instead choose to expose operations that operate on an underlying file without consumers being aware of said file.
Create an interface who's responsibility it is to return the "selected file name". Unlike most services / dependencies, it won't do a lot of processing - it's just responsible for returning a value. Use dependency injection to provide an implementor of this service to all places that need it.
At the moment this file name might seem truly global, but imagine your app had to transition from SDI to MDI. It's never a good idea to have true singletons in you composite apps.
Thanks for both answers, both of which look very good. I came up with a third approach while out on my morning run, and I think I'm going to try this one:
I load all of the modules in my Composite WPF app at startup and activate only the views that will be shown initially. So, all of my modules, even the ones not shown, are available as soon as startup completes.
When they are initialized, each module that needs the file path will subscribe to a FileOpened composite event in the Prism event aggregator. When a file is opened from the Shell, the Shell View Model will publish a FileOpened composite event. The composite event will carry the file path as its payload.
So, when the FileOpened event is published by the Shell view model, the appropriate callback method in each module will be called by the Prism event aggregator, and the filePath will be passed to each module's view model.