[quote author="sneftel" date="1331912182"]
[quote]I see QAIM as a base for adaptor classes that can be used to create an interface for your own, domain specific data stores, so the data from your store can easily be represented in a list, a table, a tree, a column view or even in a QML context.[/quote]Ahh... so concrete models should be per-source, not per-schema. Thanks for that insight.[/quote]
Just to be sure: when I use the term 'data strore', I don't nessecairily mean an (SQL) data base. I mean some piece of application internal API that manages the applications data. Views on (parts of) that data may be provided by QAIM's, but there may be many such views, perhaps provided by other QAIM's, or by other interfaces entirely. I made a store in the past that provided a view through a QAIM, but at the same time also through a graphics view.
So, if you talk about providing a model per source instead of per scheme, I hope you don't think about building one huge model to visualize a single data source with many different schemes, each having its own tables & views, each having their own content? I mean: creating a QAIM to represent the structure of an SQL data source so you can make it navigable in a tree view is one thing (I did that), but trying to use a single model for your complete data access is not a good idea.
[quote]
[quote]In practice, only the cells in the 0-th column can have children, and these are expected to have the same columns as the parent items. [/quote]Got it.
So if Qt's model/view framework is not the peg for this hole, is there a different peg I'm not aware of? Some simple way to attach a QObject* to a grouping QWidget, and property names to the QWidget's descendant widgets, and get bidirectional data synchronization?[/quote]
Of what I understand of your requirements, I don't see why you think you need such a generic solution at all. I think it will only complicate your design. It sounds like you want to have a very generic mechanism to get & set values to forms, but I think you are overestimating how common the problem you're solving with that actually is. If you add in the business-logic topics of data validation, constraints, etc., then you will very soon come to the conclusion that you will need domain-specific code anyway, taking away any gain you could have had from the generic solution you devised with so much effort.
Of course, for part of the issues you can create your own generic building blocks. Creating an object that provides bi-directional binding of widgets to an objects property value is certainly doable, for instance.
