I have an architecture question. After working with Sencha for some time I'm unsure as to what is the correct use of controllers. There are two options. The first is how I've been using them so far, which is simply to capture events and perform actions accordingly. The second is a more traditional controller, which contains the logic and functions for each view and cannot see other views.
For example, lets say we had a navigation view and had a button to switch from the main view to the next view. In both uses, the 'tap' event of the button would be handled by the controller. However, in the first option, the main view controller would then directly display the next view. In the second option, the main view controller would get the next view's controller who would then have a function that would display its view.
Both of these uses are possible, but which of these did the Sencha developers intend us to use as good practice?
In different situations one or the other ways it is a good way
If you writing a component and you might use the Controller as the controller in mvc not as an event router necessarily.
If you write an small application you will feel the need to use a couple of controllers~events~routers as ST2 advertise.
In a large application you might have logic that is not directly event driven and might feel as a good idea to place it in a controller that has no refs or control thingy
Also from my experience, I am writing very large applications and I have still managed to not use Controllers. I never got into Controllers after seeing the confusing syntax while switching from ST1 to 2. I come from a Java background and I feel applying functions directly to classes without refs or handling events without routers has been much easier.
Touché bluehipy . However, I think we've diverged from the point a little. To give you some context, the point of starting this thread in the first place is because my development team and I have to organize the way we write Sencha code for the future. You could say I'm writing company wide Sencha code standards, so I have to get it right and it needs to be generic. I know there are many possible architectures when writing applications under Sencha, I just really want to know which one is more correct so that the code we write in the future is cleaner and is less susceptible to damage by future Sencha patches. I plan to do this by knowing what model they had in mind when writing it. After all, MVC has quite a few interpretations.
@bluehipy Yeah granted the Application itself is a controller, but I do not use controllers. In the end I do have controlling functions but I do so that doesn't follow the orthodox syntax. I create a main function for my applications to handle broad helper functions, and then try to fit all other processing on the separate classes in my Js files. You can think of it more of a object structure that can be found in Java.
To go with what jcorredor is saying, you should follow the correct syntax to be confident that future changes won't effect the code. The way I have done it did successfully merge from v1 to v2, though.
Mmmm I can guess what they had in mind and I like it but I wouldn't know what future will bring. Differences from ST1 to ST2 were essential.
I would not be afraid of using fully what ST2 brings on the table. I am sure that future versions will improve things and if something essential will change the transition will not be dramatic to be done.
For example if at some point controllers will not have refs and control anymore, will not be hard to re~implement it or replace them with classic event listeners.
So if you wirte "Sencha code" follow the Sencha ways
What can I say Jerome, I love controllers because they force me to organize code better. Generally I use one for each view or group of views to handle related events. I am seeing them as a chance to keep my views really clean.
I am sure that application ca be done without the controllers but I like to use the framework