Open mhugo opened 7 years ago
+1 but why only for XML tree ? it will mean the identify dialog behaviour is different between XML/DB mode. can we manage to have one coherent approach ? everything revolves around the xsd then the content is either instantiated in XML or DB mode.
The "XML mode" is made of a geometry layer with a special "xml" attribute on each feature that contains the XML subtree. A widget displays it as a tree.
In "DB/relational mode", several layers are created with links between them, with each layer having attributes with "regular" types (well sometimes including arrays), but there is no need here for a special "tree" widget. Or am I missing something ?
you're right. I guess I am trying to mutualise things too much. Still we have to ensure the mechanics in the background are mutualised as much as possible (ex : append, content negociation).
The current plugin uses kind of a "hack" to "augment" the identify dialog and display a custom XML tree QT widget.
QGIS apparently allows to declare custom editor widgets, even in Python. See for example https://github.com/elpaso/qgis-formawarevaluerelationwidget/blob/master/FormAwareValueRelationWidget.py#L163
This should result in a better, more maintainable code.