Quote Originally Posted by gsQT4
I posted this question in the QTForums.org, but no one seems to have a suggestion.
QtForum is practically dead.

In QT 3.2, I wrote a simple client application to view, update and insert service tickets into a database. I wanted the data displayed in a form and not a table, so I used the QSqlForm class. There are several QSqlForm examples shown in QT3 books and the online doc. QT 4.1 no longer uses QSqlForm. While the class is still available, QT 4.1 uses the model view concept for displaying data. There are a few model/view convenience classes, but those are table and list views.

I've re-written the app I had written in 3.2 to work with QT4. Instead of using QSqlForm, I have a function that populates all the fields with the data from a query's current record. I use a similar function to insert and update data records. But, I'm not sure this is the best approach for writing a client application. How does one write a form style application in QT4 using the model view architecture? The model view design interests me, because it appears to allow one to easily write a 3-tier client/server application in QT. If my understanding of the model/view is incorrect, please let me know.
First step is to define your model properly. I assume you know (or will find a way) how to do it. The second step is to connect the model to your widgets. Unfortunately Qt4 itself doesn't provide an easy way to do this with all the widgets, but signals and slots are your friends here. In my opinion you should implement a QObject subclass which would serve as a controller between the model and widgets handling different fields. The controller has to do two things:
1. Make sure widgets always display up to date data
2. Commit changes made by the widgets to the model

For the first step, model signals like dataChanged(), layoutChanged() and reset() will be usefull.
For the second, you should connect signals emitted when the data changes from the widgets to your controller.

The last thing to do is to provide an architecture for connecting and disconnecting widgets from the controller.

I started to implement such a solution myself, but currently I don't have time to finish my controller architecture, but it's no big deal.