• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

How to interpret the term "GUI" ?

 
Ranch Hand
Posts: 111
PHP Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In my package design, i consider Model, View and Controller all as part of the GUI. But the MVC architecture does not specify what kind of View is used (that is in fact one of the advantages of it).
So a "graphical user interface (= GUI)" is only one of the possible views which can be plugged in. But also text-based or even sound-based "views" are possible within this architecture !!!
That makes me think that the controller and model classes do not belong in a package ~.gui, but rather in a package called ~.client or so.
The gui package (maybe better called ~.swingview) would then be a subpackage of the client package.
Who wants to shoot at my consideration... ? ;-)
GReetz Klaas

[ August 26, 2004: Message edited by: Klaas van Gelder ]
[ August 26, 2004: Message edited by: Klaas van Gelder ]
 
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think the model is the data base and controller is something that stays in between the model and the view.
I think the controller could have methods like delete all data base, even though the model does not have this ability.
The gui is something that stays at the top of them and could be in a packet suncertify.gui
If we were supposed to make a web-based system, perhaps our "gui" could stay in suncertfy.web (where there would be servelets).

finally, I don't think Model and coltrol should be in the same packet as the view. Was it what you said or am I wrong?

Itapaj� Takeguma
 
Klaas van Gelder
Ranch Hand
Posts: 111
PHP Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanx Itapaje, i think we agree on the point that model and controller are not part of the gui !
I wonder in which package you have placed these classes. The root package suncertify appears too general to me.
Grtz Klaas
 
Ranch Hand
Posts: 197
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It depends on what you mean by model.

If you mean Swing model eg TableModel, then although a complex GUI may warrant separate packages, it is equally arguable that they can all go in the same package. As regards is M, V or C GUI or not, then with this definiation of model, yes they most certainly are all GUI. Although a Swing Model class could be used for another kind of view, it would be a bad idea.

On the other hand, if you mean by model, the business model. Then yes that should be in a different package. The only big question is do you put htat package server side or client side?

Which neatly segues into a discussion about thin vs thick clients
 
Klaas van Gelder
Ranch Hand
Posts: 111
PHP Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanx mike for your reaction.

As i said, I made my mvc implementation completely Swing independent, so that any view can be "plugged in".
Maybe I can visualize it a bit using the following "pseudo-UML":

ViewReference
     Δ
     |
  (implements)
     |
MainWindow <>(N)------(1)-> GuiController <>(1)----(1)-> FlightDataModel <>---> FlightDataServices

The only Swing-based class in this scheme is the MainWindow, which also implements the ViewReference interface. This interface implements some generic methods for retrieving data from the view and updating the view, and is passed as an argument in the Controller constructor.

So my FlightDataModel is a "business model", holding a reference to the (local or remote) database services. It has nothing to do with JTable or the TableModel.
Instead, the tableModel is considered as part of the Swing-based view, and actually is added as an observer of the FlightDataModel (which extends Observable).

So i think we agree that my model and controller classes are not part of the GUI. In my opinion, they belong to the client and certainly not to the server. The (local or remote) FlightDataServices could be considered as a middleware layer, but because we have no separate middle-tier, it becomes part of the client.
Greetz, Klaas
[ August 26, 2004: Message edited by: Klaas van Gelder ]
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic