I need to convert a read parameter to type write, which means allocating an extra parameter id and duplicating the <Param> tag from the read parameter, which feels like some syntactic overhead.
I am probably missing something so I am wondering if it is possible to have a read/write parameter with only 1 <Param> tag, and thus only 1 parameter id? What is the advantage of having to specify two <Param> tags when you want to convert to a write parameter, which basically only adds a setter='true' attribute?
A side effect of the current approach is that you can only display the read parameter in the element card, but this seems purely a visual configuration.
I would say there are multiple aspect to it.
- This makes it easy to define what needs to be displayed where.
With current approach, we can indeed easily chose to:- display a read-only on page A
- display a write-only on page B
- display a read-write on page C
- This makes it easy to validate a write value in a QAction before copying it to the read value. Someone enters a new value, via the write parameter which triggers a QAction allowing to validate the value and to decide if
- the value should be accepted -> copied to the read
- the value should be accepted with some tweaking first -> alter the value somehow and copy the result to the read
- the value should be rejected -> log or display a popup why the value is rejected
- This makes it easy to run different code when the read value changes vs when the write value changes.
- When polling from data source, the read param will be altered -> we can trigger QAction A with some logic.
- When user changes the value via the UI, the write param will be altered -> we can trigger QAction B with some other logic.
- When developer changes the value by other means -> We can chose to apply the value update on the read parameter or on the write parameter depending on the QAction/logic we want to be triggered from it.
Note that when simply updating a value from a QAction standard set, no QAction will be triggered.
This is more for when you update a parameter from an action in protocol or from other locations/tools/DataMiner modules...
- As mentioned by Jeroen already, it makes it easy to have different possible values in the read and the write parameter. Example:
- read parameter allows values from A to Z to be read from the data source.
- write parameter allows a user to update the parameter to value A & B only.
- The overhead of having to create 2 parameters is, to me, quite neglect-able when using DIS
That being said, all of the above could probably have been achieved in some other ways using only one param and some properties on it. This brings me to the last aspect which is more of a historical aspect which might sound less glorious but is no shame either if you ask me. Some choice had to be made in the early stage of DataMiner, this way was chosen at the start for some reasons and we kept it along the way as, even though we could see this as a bit duplicate work, again, I don't think it's that bad either especially with DIS.
That being said, nothing is written in stone. We could always re-evaluate this. The question then becomes: how far would it really be worth the effort?