File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Swing / AWT / SWT and the fly likes Data Models Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Swing / AWT / SWT
Bookmark "Data Models" Watch "Data Models" New topic

Data Models

Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15302

Can someone provide me with link(s) on Data Models in regards to Swing Forms. I would like to see some different theories on how to keep track of data contained in TextFields, TextAreas, ComboBoxes, etc.

GenRocket - Experts at Building Test Data
Chantal Ackermann
Ranch Hand

Joined: Sep 28, 2000
Posts: 508
hi Gregg,
I know only of one "theory" about data models: the Model-View-Controller Pattern.
Examples for this pattern are JTable and its TableModel where the Controller functionalities are shared between the view and the model.
I find it helpful to think of all graphic components as views that don't care of any data they display. They don't have to check anything they just have to dispatch an event when they get changed by the user. This is the part where the controller comes in: the controller knows of the view and of the model, while the view only knows of the model, and the model is independent of anything (but the data, though it could be empty of course). Thus, the view listens to the model and dispatches events. these events will normally be listened to by the controller which will in turn do anything necessary (check the data, modify the model, change states (= change the view)). Of course, as the view knows of the model, it could change data directly on the model, as well. I don't think that does any harm (haven't experienced any). The important thing is, IMHO, to make changes of one type at one place in the code, and to be consequent and logical. That way, you might have a chance to understand your code even after some weeks.
How you design the model(s), how many components it supplies with its data - that's your decision.
Normally, you should come up with something like:

Where the model has get methods that enable the view to retrieve the values to fill its components with.
You get certainly plenty of hits searching for >Model View< on Google.
I agree. Here's the link:
subject: Data Models
It's not a secret anymore!