I'm programming in wxpython and I'm trying to use the mvc model. But I'm stuck with a lost controller :) I'll explain.
A have a panel which calls a controller. I do some things. then I destroy my controller and my panel. Well I try.
del self.tempMApanel.controller
self.tempMApanel.Destroy()
What I know for sure is that the controller isn't linked anymore with the panel because if I 'print' the controller I get an error that says main object has no attribute controller:
print "self.tempMApanel.controller: ",self.tempMApanel.controller #'Main' object has no attribute 'controller'
At a certain moment I recreate the panel with a new controller. But when I send a message (with pub.Sendmessage) to do something in the controller, the message is picked up by the old controller which isn't connected to a panel and the program complains (ofcourse :) )
SO my specific question is, can you 'kill' a controller and is it possible to have a 'lost', 'single', 'flying' controller?
The past 2 days programming was lifted to another dimension of difficult. All the virtual connections ... sometimes it is difficult to keep track and it is difficult to explain and ask for help. So I hope it is clear what I'm trying to say.
tx in advance and I hope there are some geniuses who can help me!
My day is so good!! I was talking about my 'lost' controller problem with our IT-guy and he said you use a subscriber, maybe your reference to your controller is still in there somewhere. And indeed, the controller was added to a list, so I had to remove the controller from this list and then I could remove my view.
I'm so relieved! The last 3 days there were so many problems in my program and I solved them all but this one. But now I can move on the next part.
So my advice is, always look for references if you see this kind of problem.
I work in a team of 25 developers. We use ExtJS MVC pattern of Sencha. But we believe that their definition of MVC is misleading. Maybe we might call their MVC an anti-pattern too.
AMAIK, in MVC controller only knows the name or the path of the view, and has no knowledge on the view's internal structure. For example, it's not the responsibility of the controller, whether view renders the list of customers a simple drop down, or an auto-complete.
However, in Ext JS's MVC, controller should know the rendering of view's elements, because controller hooks into those elements, and listens to their events. This means that if an element of the view change (for example a button become a link), then the relevant selector in the controller should change too. In other words, controller is tightly-coupled to the internal structure of the view.
Is this reason acceptable to denounce Ext JS's MVC as anti-pattern? Are we right that controllers are coupled to views?
UPDATE (March 2015): Ext 5.0 introduced ViewControllers that should address most of the concerns discussed in this thread. Advantages:
Better/enforced scope around component references inside the ViewController
Easier to encapsulate view-specific logic separately from application flow-control logic
ViewController lifecycle managed by the framework along with the view it's associated with
Ext 5 still offers the existing Ext.app.Controller class, to keep things backwards-compatible, and to give more flexibility for how to structure your application.
Original answer:
in Ext JS's MVC, controller should know the rendering of view's elements, because controller hooks into those elements, and listens to their events. This means that if an element of the view change (for example a button become a link), then the relevant selector in the controller should change too. In other words, controller is tightly-coupled to the internal structure of the view.
I actually agree that in most cases this is not the best choice for the exact reasons you cite, and it's unfortunate that most of the examples that ship with Ext and Touch demonstrate refs and control functions that are often defined using selectors that violate view encapsulation. However, this is not a requirement of MVC -- it's just how the examples have been implemented, and it's easy to avoid.
BTW, I think it definitely can make sense to differentiate controller styles between true application controllers (control app flow and shared business logic, should be totally uncoupled from views -- these are what you're referring to), and view controllers (control/event logic specific to a view, tightly-coupled by design). Example of the latter would be logic to coordinate between widgets within a view, totally internally to that view. This is a common use case, and coupling a view-controller to its view is not an issue -- it's simply a code management strategy to keep the view class as dumb as possible.
The problem is that in most documented examples, every controller simply references whatever it wants to, and that's not a great pattern. However, this is NOT a requirement of Ext's MVC implementation -- it is simply a (lazy?) convention used in their examples. It's quite simple (and I would argue advisable) to instead have your view classes define their own custom getters and events for anything that should be exposed to application controllers. The refs config is just a shorthand -- you can always call something like myView.getSomeReference() yourself, and allow the view to dictate what gets returned. Instead of this.control('some > view > widget') just define a custom event on the view and do this.control('myevent') when that widget does something the controller needs to know about. Easy as that.
The drawback is that this approach requires a little more code, and for simple cases (like examples) it can be overkill. But I agree that for real applications, or any shared development, it's a much better approach.
So yes, binding app-level controllers to internal view controls is, in itself, an anti-pattern. But Ext's MVC does not require it, and it's very simple to avoid doing it yourself.
I use ExtJS 4's MVC everyday. Rather than spaghetti code, I have an elegant MVC app that has tightly defined separation of concens and is ridiculously simple to maintain and extend. Maybe your implementation needs to be tweaked a bit to take full advantage of what the MVC approach offers.
Of course the controllers are bound to the views in some way. You need to target exactly which elements in your views you want to listen to.
eg: listen to that button clicks or to that form element change or to that custom component/event.
The goal of MVC is components decoupling and reusability and the Sencha MVC is awesome for that. As #bmoeskau says, you have to be careful in separation of the view controllers (builtin for the view/widgets itself) and the application controllers (top level views manipulations) to take full advantage of the MVC pattern. And this is something not obvious when your read http://docs.sencha.com/ext-js/4-1/#!/guide/application_architecture. Refactor your MVC approach, create different controllers, create custom component, and embrace the full ExtJS MVC architecture to take advantage of it.
There's still a slight problem in Sencha approach IMHO, the MVC refs system doesnt really work when you have multiple instances of the same views in an Application. eg: if you have a TabPanel with multiple instances of the same Component, the refs system is broken as it will always target the first element found in the DOM... There are workarounds and a project trying to fix that but i hope this will be adressed soon.
I'm currently undergoing the Fast Track to ExtJS 4 from Sencha Training. I have a strong background in ExtJS (since ExtJS 2.0) and was very curious to see how the MVC was implemented in ExtJS 4.
Now, previously, the way I would simulate kind of a Controller, would be to delegate that responsibility to the Main Container. Imagine the following example in ExtJS 3:
Ext.ns('Test');
Test.MainPanel = Ext.extend(Ext.Container, {
initComponent : function() {
this.panel1 = new Test.Panel1({
listeners: {
firstButtonPressed: function(){
this.panel2.addSomething();
},
scope: this
}
});
this.panel2 = new Test.Panel2();
this.items = [this.panel1,this.panel2];
Test.MainPanel.superclass.initComponent.call(this);
}
});
Test.Panel1 = Ext.extend(Ext.Panel, {
initComponent : function() {
this.addEvents('firstButtonPressed');
this.tbar = new Ext.Toolbar({
items: [{
text: 'First Button',
handler: function(){
this.fireEvent('firstButtonPressed');
}
}]
});
Text.Panel1.superclass.initComponent.call(this);
}
});
Test.Panel2 = Ext.extend(Ext.Panel, {
initComponent : function() {
this.items = [new Ext.form.Label('test Label')]
Test.Panel2.superclass.initComponent.call(this);
},
addSomething: function(){
alert('add something reached')
}
});
As you can see, my MainPanel is (besides the fact that is holding both panels) also delegating events and thus creating a communication between the two components, so simulating sort of Controller.
In ExtJS 4 there is MVC directly implemented in it. What really striked me was that the way the Controller actually fetches the components is through QuerySelector which in my opinion is very prone to error. Let's see:
Ext.define('MyApp.controller.Earmarks', {
extend:'Ext.app.Controller',
views:['earmark.Chart'],
init:function () {
this.control({
'earmarkchart > toolbar > button':{
click:this.onChartSelect
},
'earmarkchart tool[type=gear]':{
click:this.selectChart
}
});
}
});
So as we can see here, the way the Controller is aware of the earmarkchart button and tool is through selectors. Let's imagine now that I am changing the layout in my earmarkchart and I actually move the button outside of the toolbar. All of a sudden my application is broken, because I always need to be aware that changing the layout might have impact on the Controller associated with it.
One might say that I can then use itemId instead, but again I need to be aware if I delete a component I will need to scatter to find if there is any hidden reference in my Controllers for that itemId, and also the fact that I cannot have the same itemId per parent Component, so if I have an itemId called 'testId' in a Panel1 and the same in a Grid1 then I would still need to select if I want the itemId from Panel1 or from the Grid1.
I understand that the Query is very powerful because it gives you a lot of flexibility, but that flexibility comes at a very high price in my opinion, and if I have a team of 5 people developing User Interfaces and I need to explain this concepts I will put my hands on the fire that they will make tons of mistakes because of the points I referenced before.
What's your overall opinion on this? Would it be easier to just somehow communicate with events? Meaning if my Controller is actually aware of what views he's expecting events, then one could just fire an event dosomethingController and the associated Controller would get it, instead of all this Query problem.
I think if you use the Sencha Architect to produce the Views then Inherit from that View to create Your own View.
Now this View Can be responsible to hook up to any events and raise meaningful events.
This is just a thought...
//Designer Generated
Ext.define('MyApp.view.MainView', {
extend: 'Ext.grid.GridPanel',
alias: 'widget.mainview',
initComponent: function() {
}
});
//Your View Decorator
Ext.define('MyApp.view.MainView', {
extend: 'MyApp.view.MainViewEx',
alias: 'widget.mainviewex',
initComponent: function() {
this.mon(this, 'rowselect', function(){
this.fireEvent('userselected', arguments);
}, this);
}
});
I think there is a pretty bad problem here - its very difficult to shard isolated units within a page.
The approach I'm experimenting with (which makes it somewhat easier to write tests aswell) is to have a vanilla js context object for each page which contains the logic (and has the benefit of being very easy to break up and delegate to different objects). The controllers then basically call methods on the context objects when they receive events and have methods on them for retrieving bits of the view or making changes to the view.
I'm from a wpf background and like to think of the controllers as code-behind files. The dialog between presenter/context and view is a lot chattier than wpf (since you dont have binding + data templating) but its not too bad.
Theres also a further problem I haven't had to solve yet - the use of singletons for controllers causes problems for reuse of UI elements on the same page. That seems like a serious design flaw. The common solution I've seen is (yet again) to pile everything into one file and in this case to ditch the controller altogether. Clearly that's not a good approach as soon as things start to get complicated.
It seems like getting all the state out of the controller should help though and you'd then have a second level of context objects - the top level one would basically just assign a unique id to each view and have a map of context=>view and provide dispatch to the individual context methods - it'd basically be a facade. Then the state for each view would be dealt with in the objects dispatched to. A good example of why statics are evil!
In Cocoa MVC adoption, View knows nothing about the Model, which illustrated in this diagram:
But consider this example:
I have Item class in my model and I want visual representation for it. Most obvious for me is ItemView class, which is initialized with Item.
So, in this way, I'm breaking Cocoa MVC rules and feeling uncomfortable with it. But, I'm feeling uncomfortable also not having class like ItemView. What is the most practical solution?
If you are really concerned about MVC, what about defining a method in your controller like:
- (UIView*)itemViewForItem:(Item*)item;
which is responsible for creating and "populating" your ItemView?
You main controller class would then act as a controller both for your main view and all ItemViews you have got.
Another approach would be giving each ItemView its own ItemViewController. This is perfectly fine and if your controller/view is of any complexity, IMO, also the best approach. The drawback with this is that dealing with controllers container is supported only on iOS>5.
I'm working on my first C#/WPF project (I'm a Java/Web developer with some Flex/As experience). The MVVM pattern seemed to be the way to go so I've started climbing the learning curve...
I'd like to know what's considered as the way to go to notify state modifications between related ViewModel objects.
Long story short, I have a UserControl containing a TreeView that is bound to a ReadOnlyCollection exposed by MyTreeViewModel.
SomethingViewModel implements INotifyPropertyChanged and generates an event when its 'IsSelected' property is changed.
MyTreeViewModel has an event handler attached to the PropertyChanged event of SomethingViewModel and updates a property that it manages called 'CurrentlySelectedElement'.
MyTreeViewModel also implements INotifyPropertyChanged and generates an event when its 'CurrentlySelectedElement' property changes.
Finally, I have an event handler in another ViewModel class that handles the selection change.
Is this a correct way of approaching this in C#/WPF?
Also, I'm not really fond of using property names with Strings in my event handling methods; It doesn't seem very refactoring friendly to me.. For now, I've dealt with this by exposing the property name as a static string, so that I can simply use the following in my event handler method:
if(SomeViewModel.PROPERTY_IS_SELECTED.Equals(e.PropertyName)) { ... }
Do you know a better alternative? I guess there should be a way of doing this but to be honest I didn't investigate that any further yet.
Thanks for your feedback!
Check out the Event Aggregator pattern. There are quite a few implementations out there. If you're using a MVVM framework ( https://stackoverflow.com/questions/1280462/what-mvvm-framework-are-you-using, What framework for MVVM should I use? ), chances are it will contain an implementation as well.
I have to implement an Form View, or in other words: A class that is used to put a complex input form on the screen.
The Form is built up of FormComponents. There is an addFormComponent() Method to compose the form with these. And then, the form has an isValid() Method which will go through all the FormComponents and check their associated FormValidators.
For sure this thing has a lot of "intelligence", but most of this is just a call to some other class. For example the isValid() method does cool stuff, but it really only calls the isValid() methods of the FormComponents which are registered in an array. Nothing too fancy.
Well, that beeing said, must I make a fat FormViewController for this, or is an View just fine?
My understanding of these is, that a ViewController is used when there's some big logic involved. In this case, the Form View has a template which will simply iterate over the FormComponents and include them. Each FormComponent has it's own template in turn and does it's own stuff.
I've always been struggling with ViewController and View and I think I'll keep on doing that until I get a nice R.I.P. brick... but maybe someone can clear this up a little bit ;-)
The purist in me is saying that this belongs in a ViewController. I guess maybe it would depend on the framework you are using. For example, this type of setup would be very easily implemented in a Spring Controller object. It sounds like creating a controller in your case would be a lot of extra work.
Nothing is ever set in stone. You can implement in the View for now and if this turns out to be a huge burdon, move it to a Controller class. Knowing when to refactor is the difficult part.