amirs
12-06-2008, 01:58 AM
Hi everyone,
I've been trying to write my application based on the MVC structure and I have a few questions about the client side.
Currently my understanding is that the structure should be roughly this:
* A dispatcher
* A number of controllers, each informing the dispatcher which events they are interested in handling and each containing one or more views so that they can forward it events.
* A number of views, each containing a controller so that they can send it events.
One of the key features of an MVC structure is the modularity - I build three different parts which are able to interact with each other but are not dependent of each other. This means that I can replace each part with a similar one without the other two parts having to be changed.
Say I want to write two different views. One as a web site and one as a commandline application. MVC means that all of my logic should be in the Model and Controller parts and I should be able to replace the View because it's only how I see things.
BUT, currently in GXT the View class gets a Controller parameter in its constructor. And from what I saw in the MailApp example the Controller is the one who creates the View and then passes it "this" as an argument. Since this means that the View depends on the controller, I would have to write a new controller with exactly the same logic in order to create a new view.
And so I have one question and one idea I would like to hear your opinion on:
Question - why does the View need to get a Controller as an argument in its constructor?
I read in some other thread someone saying that in a true MVC structure the Controllers and the Views would not contain each other or know of each other's existence by any means. They would communicate strictly using events.
Idea - I couldn't find a solution to this anywhere yet so I came up with a few ideas of my own:
1. The View class would receive as a parameter another class that would be the actual view in the MVC sense of the word. The new child view class would be the one drawing the widgets or printing output to the shell. The problem with this is that it seems like an ugly solution because I end up with the old View class being nothing but a bridge.
2. I would write a TemplateRegistry class which would receive a set of classes that each implement an interface with the need functionality. I would have a Login interface and an Error interface and a Home interface. The TemplateRegistry class would define which set of instances it needs and which interfaces each of them must implement. At the very beginning of the application I would demand that the TemplateRegistry be filled with a set of instances as a sort of configuration. This way I would have a set for the web page and a set for the commandline. If I write it correctly I could even mix classes from each set and it would still work.
I've read posta07's excellent guide (http://www.christianposta.com/blog) but I couldn't find my answers there.
I would love to here any opinions on this subject (and sorry the post came out so long...).
Thank You!
I've been trying to write my application based on the MVC structure and I have a few questions about the client side.
Currently my understanding is that the structure should be roughly this:
* A dispatcher
* A number of controllers, each informing the dispatcher which events they are interested in handling and each containing one or more views so that they can forward it events.
* A number of views, each containing a controller so that they can send it events.
One of the key features of an MVC structure is the modularity - I build three different parts which are able to interact with each other but are not dependent of each other. This means that I can replace each part with a similar one without the other two parts having to be changed.
Say I want to write two different views. One as a web site and one as a commandline application. MVC means that all of my logic should be in the Model and Controller parts and I should be able to replace the View because it's only how I see things.
BUT, currently in GXT the View class gets a Controller parameter in its constructor. And from what I saw in the MailApp example the Controller is the one who creates the View and then passes it "this" as an argument. Since this means that the View depends on the controller, I would have to write a new controller with exactly the same logic in order to create a new view.
And so I have one question and one idea I would like to hear your opinion on:
Question - why does the View need to get a Controller as an argument in its constructor?
I read in some other thread someone saying that in a true MVC structure the Controllers and the Views would not contain each other or know of each other's existence by any means. They would communicate strictly using events.
Idea - I couldn't find a solution to this anywhere yet so I came up with a few ideas of my own:
1. The View class would receive as a parameter another class that would be the actual view in the MVC sense of the word. The new child view class would be the one drawing the widgets or printing output to the shell. The problem with this is that it seems like an ugly solution because I end up with the old View class being nothing but a bridge.
2. I would write a TemplateRegistry class which would receive a set of classes that each implement an interface with the need functionality. I would have a Login interface and an Error interface and a Home interface. The TemplateRegistry class would define which set of instances it needs and which interfaces each of them must implement. At the very beginning of the application I would demand that the TemplateRegistry be filled with a set of instances as a sort of configuration. This way I would have a set for the web page and a set for the commandline. If I write it correctly I could even mix classes from each set and it would still work.
I've read posta07's excellent guide (http://www.christianposta.com/blog) but I couldn't find my answers there.
I would love to here any opinions on this subject (and sorry the post came out so long...).
Thank You!