Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Complications decoupling View and Controller

 
Sam O'Neill
Ranch Hand
Posts: 57
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi everyone.
Mark I decided to follow your advice regarding the separation of View and Controller so now my View implements an interface that provides methods for adding Actions to particular GUI components e.g.

and my Controller then calls these methods on the View passing in Actions defined as inner classes in the Controller.
So far so good.
My worry is that from here my View interface then started to become more and more complex to accommodate the lack of reference to the Controller as it has to provide methods to allow the Controller to query the View for information such as the selected row in the JTable, the selected flight origin and destination and the DB path/IP address of the database file to be used.


In addition to this my View also provides methods to show() and hide() the various dialogs and the main View itself so that the View and all of its components can be constructed first then passed to the Controller without yet being displayed. The Controller then takes charge of calling the show() methods once its Actions have been constructed and passed to the View to attach to the components that will trigger them.
So now I have...

So my concern is that my interface that my View must conform to for the Controller to work is raging out of control in size and that I am missing something here which will allow my Controller to obtain the relevant information from the View without inflating the number of hook methods the View must implement.
I remember reading one of your mails Mark that mentioned the way to decouple the View and Controler was by using Actions. Could you elaborate on this as I am using Actions because I have duplicate menu options and buttons bt am unsure how the Actions can be used to obatin information from the View without requiring the View to implement hook methods.
What I am basically asking is how do I find out what row has been selected in the View if my View has no reference to the Controller and I don't provide a hook method in the View?
Sorry if this has turned into an epic to rival 'War and Peace' but really am stumped by this. If the View implements such a large interface for the Controller are they not then still highly coupled in any case?
Many, many thanks for any input - much appreciated.
Sam
 
aadhi agathi
Ranch Hand
Posts: 263
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Sam O'Neill:

My worry is that from here my View interface then started to become more and more complex to accommodate the lack of reference to the Controller as it has to provide methods to allow the Controller to query the View for information
hook methods the View must implement.
Sam

One way is to remove the Controller altogether and have only View and Model. .
the main reason for this is the View can't be treated like a normal Class. for example the BookView is not equivalent to a Book Class. Search view is not a Search class and so on.

the main idea is what do u think , either View/Controller, that has reusbale potential. then you go with the hook method ot coding the View for specific controller.
1) the hook methods are those methods which will prove to be arguments to the Model via the Controller. if these arguments can be done in a Collection you had it.
but if you are saying when my book method is
processed my View should change (change the cursor, background color, enable disable of components) then the controller will call setValue method of the view and the view will decorate itself.
then you will have only get and set but if the Controller can iterate the collection and get the arguments , there is nothing like that. think about it.

say you have a view which has the operations DeleteRecord, InsertRecord and UpdateRecord then imagine how awkward to use it via the Controller . Controller doesnt do any good and it is used only for the sake of MVC.
2) IMHO Controller should be only used when there is a deep problem in the mapping. otherwise
Observer-Observable( View-Model) is suitable in 805 of the cases.
[ January 28, 2003: Message edited by: aadhi agathi ]
 
Sam O'Neill
Ranch Hand
Posts: 57
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Aadhi
I have just realised that there is another thread dealing with this very same issue so am sorry to duplicate.
Thanks again Sam
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, I have not implemented an Action "middle" class to decouple further, but here is my take on how that works.
The Action class must have a reference to the Controller so that it can call the Action method in it. The action also calls the hook methods so that it all works.
As far as all those methods in your view interface. I didn't have an interface, and all the objects on the View are public so that I can access the values in the view. You can always just include some getters in the view, but I opted for the objects to be public.
So my code for getting the selected row is.

simple as that. As you can see though I did also have a getter for retreiving the JTable, because I have it in a JPanel within the Main screen.
Hope that helps.
Mark
 
Sam O'Neill
Ranch Hand
Posts: 57
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Okay so my opting to make all my components private has led to the explosion of getter methods.
I thought I ought to have the view implement an interface as the controller depended on the hook methods being provided by the view so by my reckoning if there was an interface the view was free to change all the components and layout used without affecting the controller as long as it implemented the hooks the controller was expecting. This way I don't reference any of the components in the view directly from the controller. It does complicate the view though in the number of methods it must provide.
Thanks for clearing up my confusion about the Action's role. My understanding was correct I just thought you had them performing some other special magic that I hadn't picked up on.
Thanks again Sam
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
sam that is really why I was fine with keeping the Objects on the View to being public, because isn't a GUI a public view?
To me the purspose of the View is to display, and therefore everyone sees it, it doesn't have much code elsewhere, I just have my Hook methods, since all the objects in the GUI are public, I have access to them.
If you have any other type of class that has the instance variables as private then you will always have lots of getter and setter methods, that is part of the JavaBean rules.
So is it really that difficult to read. Do you have to have getters for all the objects on the form?
Good Luck
Mark
 
John Smith
Ranch Hand
Posts: 2937
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Okay so my opting to make all my components private has led to the explosion of getter methods.

To reduce the number of getters (and I'd lke to pint out that you don't need any setters), you could group together the data pieces and pass them all in one call. For example, if the Controller needs to know the parameters for the remote connection that are set in the View, you could have something like this in the controller:
ConnectionParameters cp = view.getConnectionParameters();
int port = cp.getPort();
String serverDNS = cp.getServerDNS();
String databaseName = cp.getDbName();
...
Eugene.
 
Esem Tax
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have the same basic structure.
But by the way, for my menu help item, i put that all in the View, i mean the handling of the selection of the menu item and the launching of the help dialog.
Do you consider this a violation of the abstraction roles? I figured that the Controller only had to worry about controlling anything that had to do with the Model.
[ February 01, 2003: Message edited by: Esem Tax ]
 
Sam O'Neill
Ranch Hand
Posts: 57
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think the question of public or private components in the GUI is a classic example of there being no clear winner of an answer just the design you feel happiest justifying:
With public components access from the Controller is simple and the View is only required to implement the hook methods for the Controller to be able to interact with it. The downside being that the Controller must know all about the View's components.
With private components the View must also implement getter methods, causing greater complexity in the View, to give the Controller access to these components. But encapsulation of the View is maintained and the Controller need have no knowledge of the exact layout or components used by the View.
The former option could be argued to provide less coupling in that less is expected of the View for the Controller to be able to do its job - the View need not provide a large interface for the Controller to utilise. But the latter option
could be a candidate for less coupling in that the Controller requires no knowledge of the View's internals and is free to change as is the view provided the View conforms to the interface the Controller is expecting.
Mmmmn will have to ponder this some more.

If you have any other type of class that has the instance variables as private then you will always have lots of getter and setter methods, that is part of the JavaBean rules.
So is it really that difficult to read. Do you have to have getters for all the objects on the form?

Thanks for this Mark - I now realise it is not incorrect to have these getter methods.
Eugene also I will consider the idea of grouping the requests into one.
Esem, in my opinion the Controller should be aloowed to do just that regardless or whether the Controller's actions result in a call to the Model.
Thanks everyone Sam
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic