[Qt-interest] QTableView::addColumn()
Sebastian Fischer
creat at gmx.net
Mon Dec 22 16:32:51 CET 2008
NOTE: Sorry, I had already sent this but for some reason it seems it
never appeared on the list, so this is the next try...
on 20.12.2008 at 13:17 you wrote:
> On Saturday 20 Dec 2008 5:05:03 pm Sebastian Fischer wrote:
>> on 20.12.2008 at 10:50 you wrote:
>> > Why there is no suchmethod like QTableView::addColumn() ?
>> > in Model View architecture some data maynot come from model.
>> > may be a check box or a edit button or a total, avg column that are
>> > calculated by the data from other columns.
>>
>> That would be exactly something the model would do. If you want this
>> just return +1 columns form the model (in case it's a custom model)
>> and do your calculations there. If you have some other base model
>> (like SQL or FileSystem and so on) create a simple proxy model that
>> doesn't do anything but add that column (or allow users to dynamically
>> add various sorts of sum columns and other stuff).
> Model means it delivers concrete data.
> when you are making a table suppose a marksheet table marks of subjects of
> different students are the concrete values
> Total and avg are for representation and they are not going to take any place
> on record or storage.
> so they should not come from model.
These totals and averages are still concrete data, it doesn't matter
if it can be calculated from other values. The view isn't suppsed to
'create' any data, even if it's just a modification of the raw data
stored somewhere. The model also doesn't (necessarily) just provide
acces to the data that is stored.
The model should provide all data a view MIGHT need (including these
calculated columns for example), the view can then pick which ones to
display. That's why the Table/Tree views have the setColumnHidden
functionality.
>> As the name 'View' suggests, it doesn't do anything but show you
>> content (and maybe let you edit it). Data storage / calculations
>> should be done where the data belongs, in the model.
>>
>> > all this columns are not a part of model so there should be an
>> > addColumn() method on view also so that data that are not coming from
>> > model would not have any relation with model
> why would there be a representation specific overhead on model ??
> When you are isolating view for representation all representation specific
> things should go in View.
> Both model and view might have calculation overhead.
> but Model's calculation overhead should be limited to storage specific it
> might also deal with data to deliver something else by conditional checking.
> But it should never **CARE** for presentation layer.cause people can plug the
> same model into different views where the are viewing the **SAME THING(model
> data)** from different aspects/angles. and its not possible for a model to
> forsee all this aspects/angles.
> and view layer should always deal only with representation part and it should
> be able to do calculations specific to representation.
That's one of the things proxy models are for (at least to my
understanding). You use the same base-model for the (raw) data and if
you have the need to adapt it for specific ways of viewing it, you put
a proxy model in between, making the changes to the data for you (like
adding a column with sums of the other columns). Primarily sorting or
filtering (which btw. is also no longer the raw data, and yet it's not
the view where you make these changes). Like mentioned above, in case
you're just adding a column that isn't even necessary since you can
just hide it in views where it isn't needed/helpful.
I know all this is to some degree a matter of taste, like where the
line is drawn between models and views. At least for Qt it seems to be
pretty clear from what capabilities the classes have that models are
intended to do everything data-related and the views only display
them. And yes, the views have sortingEnabled properties, they don't
actually sort the data though, but relay it to the model (it's just to
allow you to set the sorted column by clicking on the header and
such).
Bye,
Sebastian Fischer
More information about the Qt-interest-old
mailing list