Application Test Panel as a new DQMH component (dream big)

[1984]

Idea:

Create a new DQMH component almost identical to the API Tester and call it Application Test Panel (ATP from now)

Loose definition of the ATP: a user interface visible to the end user in the final application which provides access to the DQMH functionalities in an application specific way.

Reason:

In many application an ATPs should be provided so the user can play around with different parts of the application. The DQMH module itself has the core functionality and its generic, the API tester is for testing the functionality of the module, and the ATP would be the application specific user interface.

Examples: 

1. Relay board module
   • The DQMH module is a generic relay control module. Can connect to the instrument, can open and close relays in general etc
   • the API tester is to test the module
   • the ATP would display the relay configuration the customer has in his system. The user should not be able to start or stop the module and in many cases he doesnt have to connect to the instrument as the connection built up earlier. Could have safety mechanisms like it doesnt allow to close relay K1 until relay K2 is closed etc which are not build to the DQMH module
2. Database module:
   • The DQMH module creates generic database functionalities
   • The API tester is to test the module
   • The ATP is an interface where the user can interacts with his database specifically. Could display functionalities which is a combination of the atomic requests provided by the module.

In most cases the API tester can't be used as an ATP, simply because of the reasons above: the API tester is generic the ATP is specific. Also in the vast majority of the cases we dont want to the user to be able to start or stop the module, launch a new cloneable instance etc. Another factor is the GUI design which will be most likely different for the API tester and the ATP. 

How:

The ATP is practically a second API tester. If a new request is created, an existing is renamed / removed (etc) then the change should be applied to the ATP as well. The ATP should have two extra requests by default: load to subpanel (input a subpanel reference) and an unload from subpanel, so the ATP is prepared to be shown to the user easily. 

At this point the API tester and the ATP development can be forked. The API tester works just as usual but the developer can start building a UI for the ATP.

There should be a mechanism to generate a new ATP from scratch as a given DQMH module might have a different ATP for the different applications (example: different customers have different relay layout, database structure etc).

And at the end the most obvious question:

So why not simply copy-paste the API tester? Cause the ATP should follow the changes of the DQMH module like the API tester does so the developer doesn't have to add each and every requests manually.

[1984]

I wish there be a delete idea button... this probably doesnt make too much of a sense. When a DQMH module is imported to a project it should be mature enough to not have too many changes. And if this is true then well... copying the API tester and deleting the unwanted events should be alright. This part can be automated which could be useful, but the original idea is probably mediocre at best

[joerg.hampel]

After consideration, we've decided to focus our limited resources elsewhere. The ratio between effort (a lot) and benefit (a corner case) seems not ideal.