Win a copy of The Business Blockchain this week in the Cloud forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Seperating GUI from implementation

 
Steve Harper
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi
For my client side design I have a GUI class and a controller class. The controller class creates an instance of the GUI class passing a reference to itself to the GUI class. Any interaction between the Data class and the GUI class must go through the controller.
I have also created a FlightDataModel class that extends AbstractTableModel.
I have a couple of questions.
1. Where should I put the class FligtDataModel? Should it be in the GUI class or should I have it as an inner class of the controller. If I have the FlightDataModel class in the controller class doesn't that mean I have tight coupling between the implementation and GUI by saying that the GUI will always have a table.
2. Should the GUI be hidden completely from the structure of the data i.e. the GUI should have no concept of the DataInfo class and the FieldInfo class.
My thinking is that the GUI should be hidden from the DataInfo class and FieldInfo class and that the controller class should translate the data structures either into more generic types e.g. maps and lists or by having multiple methods for retrieving the data fro the database.
Cheers
 
Sai Prasad
Ranch Hand
Posts: 560
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
For my client side design I have a GUI class and a controller class. The controller class creates an instance of the GUI class passing a reference to itself to the GUI class.
No need for the GUI to know about the controller
1. Where should I put the class FligtDataModel? Should it be in the GUI class or should I have it as an inner class of the controller. If I have the FlightDataModel class in the controller class doesn't that mean I have tight coupling between the implementation and GUI by saying that the GUI will always have a table.
I would have the JTable model in the Controller. I mean you have a seperate file for the table model and the controller has an instance of that model. It is ok to have the tight coupling between the controller and the GUI.
2. Should the GUI be hidden completely from the structure of the data i.e. the GUI should have no concept of the DataInfo class and the FieldInfo class.

Yes. GUI should not know anything about the business objects.
[ May 21, 2002: Message edited by: Sai Prasad ]
 
Nigel Browne
Ranch Hand
Posts: 703
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Steve Harper:
I have also created a FlightDataModel class that extends AbstractTableModel.
I have a couple of questions.
1. Where should I put the class FligtDataModel? Should it be in the GUI class or should I have it as an inner class of the controller. If I have the FlightDataModel class in the controller class doesn't that mean I have tight coupling between the implementation and GUI by saying that the GUI will always have a table.

I had my DataModel as a seperate file.

2. Should the GUI be hidden completely from the structure of the data i.e. the GUI should have no concept of the DataInfo class and the FieldInfo class.
My thinking is that the GUI should be hidden from the DataInfo class and FieldInfo class and that the controller class should translate the data structures either into more generic types e.g. maps and lists or by having multiple methods for retrieving the data fro the database.

The View shouldn't have any concept of the Data pkg. However the Data pkg can be considered part of the model and the controller should be aware of the model structure.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic