Addressbook example: separation of concerns
-
Hi there,
I am new to Qt but have done quite some programming in other frameworks.
I was reading through the documentation about model view programming and stumbled upon the
address book example.
I do not understand why in the example theAddressWidget::addEntry()andAddressWidget::editEntry()manipulate the TableModel by row and column (insertRows, setData) instead of using a function in the TableModel, something likeTableModel::addEntry(Contact contact)ortableModel::updateEntry().
With the current approach the AddressWidget is aware of the internals of the TableModel. Which leads to more tangled code. Now if someone wants to reorder to layout of the table, both the AddressWidget and the model should be updated, which is easy to forget and can lead to some nasty bugs.
If a function likeTableModel::addEntry(Contact contact)is created the TableModel can update it's state while the AddressWidget stays clean.
Am I missing something why the approach taken in the documentation is preferable to my suggestion?With kind regards,
Elbert@nouwaarom
Hello and welcome.You are indeed welcome to add whatever layer(s) of abstraction you wish for better code design. Qt is not a language, it's just a library of classes/functions. However you like your C++ programs to be on top of that is fine.
The Qt examples are meant to illustrate Qt calls, in minimal-ish code size. They are not bad, but not claim to be the best abstraction you might choose to write for yourself.
-
Thanks for your response @JonB ,
I understand that the documentation and examples are mainly focused on concisely explaining Qts functionality.
But I think that a lot of beginning developers may not realize which design principles are used or are violated in the documentation and examples. By providing sub-optimal examples, they may see this as "the Qt way" and stick to that.
What do you think about that? -
Thanks for your response @JonB ,
I understand that the documentation and examples are mainly focused on concisely explaining Qts functionality.
But I think that a lot of beginning developers may not realize which design principles are used or are violated in the documentation and examples. By providing sub-optimal examples, they may see this as "the Qt way" and stick to that.
What do you think about that?@nouwaarom said in Addressbook example: separation of concerns:
By providing sub-optimal examples
The examples are mostly there to show how the Qt classes work and how to deal with them. They are not examples of how a well structured and clean C++ project with Qt should look like...
Some of them can be used as a template, some of them are pure demo projects with focus on the topic, the example is all about. -
Thanks for your response @JonB ,
I understand that the documentation and examples are mainly focused on concisely explaining Qts functionality.
But I think that a lot of beginning developers may not realize which design principles are used or are violated in the documentation and examples. By providing sub-optimal examples, they may see this as "the Qt way" and stick to that.
What do you think about that?@nouwaarom
I don't agree with your feelings, I do agree with @Pl45m4. He says the same as I did: examples are to illustrate Qt. For that I want to see minimal code showing just the essentials. If instead it went for "best style at all costs" I would (potentially) be wading through reams of code which --- while quite worthy --- may take me too much time and obscure the essence of what I need to grasp. -
Thanks for your reply. I understand that you want to keep the documentation as compact and concise as possible. However, in the case of the addressbook example, the code is more complex and harder to read because
setDatais used to add data to the model from the widget, while the main purpose ofsetDatais to be used when the model is editable, which this model is not. -
Feel free to provide a patch.
-
Thanks for your reply. I understand that you want to keep the documentation as compact and concise as possible. However, in the case of the addressbook example, the code is more complex and harder to read because
setDatais used to add data to the model from the widget, while the main purpose ofsetDatais to be used when the model is editable, which this model is not.@nouwaarom said in Addressbook example: separation of concerns:
setData is used to add data to the model from the widget, while the main purpose of setData is to be used when the model is editable
No, the main purpose of this method is to apply the data to the record/row.
There is a valid reason for adding data to be divided into two atomic steps: 1) add empty rows to the model; 2) set data to the given record/row.
That reason is to provide elastic approach that can be ready used to derive model that suits the needs of the programmer.As my more experienced colleagues said - and I agree with them - you are most welcome to add to it, provide a patch, take it forward and develop further at your convenience especially if you feel that the framework is lacking some basic functionality.
-
Thanks for your reply. I understand that you want to keep the documentation as compact and concise as possible. However, in the case of the addressbook example, the code is more complex and harder to read because
setDatais used to add data to the model from the widget, while the main purpose ofsetDatais to be used when the model is editable, which this model is not.@nouwaarom said in Addressbook example: separation of concerns:
while the main purpose of
setDatais to be used when the model is editable, which this model is not.I don't follow? It is editable. The
setData()updates a row. -
Thanks for the replies. @Christian-Ehrlicher I will try that, but it might take some time to set everything up and submit a patch as I have not contributed to Qt yet.
What I meant by 'editable' is that the model is editable from the view.
For example if you addtableView->setEditTriggers(QAbstractItemView::DoubleClicked);when initializing when view.
Make sureTableModel::flagsreturnsQt::ItemIsEditablefor the columns you want to be editable.
Then the view will callTableModel::setDatafor these columns when they are double clicked and their value is updated.
I experimented a bit with that here. -
Thanks for the replies. @Christian-Ehrlicher I will try that, but it might take some time to set everything up and submit a patch as I have not contributed to Qt yet.
What I meant by 'editable' is that the model is editable from the view.
For example if you addtableView->setEditTriggers(QAbstractItemView::DoubleClicked);when initializing when view.
Make sureTableModel::flagsreturnsQt::ItemIsEditablefor the columns you want to be editable.
Then the view will callTableModel::setDatafor these columns when they are double clicked and their value is updated.
I experimented a bit with that here.@nouwaarom said in Addressbook example: separation of concerns:
Then the view will call TableModel::setData for these columns when they are double clicked and their value is updated.
So what's different from the example then? That a separate widget instead a view updates the data? Who says that 'the view' must be a single widget?
