Draft: Refactor property widget
Summary
This merge request reorganizes the propertyfesawidget in a new folder with model and view logic separated.
At a high level, I suggest structuring the files as follows:
-
Model (
_model.py) -
View (
_view.py) -
Widget Initialization (
propertyfesawidget.py) - (may be unnecessary after refactoring)
Model (_model.py)
The model should contain a class (likely inheriting from QStandardItemModel) that interfaces directly with the ccda database, supporting property subscriptions and updates. This DevicePropertiesModel needs to handle multiple properties from multiple devices, each represented as an object inheriting from FesaCommListener. Each of these objects should include a fesacomm attribute to facilitate GET and SET actions.
The model’s data structure will be more complex than the current one; however, once fully defined and validated, it will provide a flexible, robust interface that can be reused in other widgets. These could range from a widget that displays array-type property fields to a large table tracking multiple device properties.
View (_view.py)
The view should implement a class (perhaps inheriting from QWidget or a more specific Qt class suited to the layout) that binds directly to the model. Based on the initial data fetched from ccda by the model, it will dynamically set up the appropriate sub-widgets to handle specific data types. The view should also assign ItemDelegates as needed and render buttons for actions like GET, SET, and SUBSCRIBE management.
To keep the user interface organized, each device property will be displayed in a separate tab, with each individual property field mapped to an appropriate sub-widget.
Widget (propertyfesawidget.py)
To ensure backward compatibility with the existing propertyfesawidget component, this file should handle the initialization of the model and view and maintain the same public methods currently available in the widget (even if they only proxy methods from _view or _model). During implementation, we may find this extra module unnecessary and could consider consolidating PropertyFesaWidget within _view, but for now, keeping them separate allows for flexibility.