Add Specification for GPHL Json Schema form

[jbflo]

Update for Current form query_pre_strategy_params renames ui filed keys for better display of form

[github-actions[bot]]

Coverage Report •

File	Stmts	Miss	Cover	Missing
mxcubecore/HardwareObjects/Gphl
GphlWorkflow.py	1272	1272	0%	4–3032
TOTAL	60524	56207	7%

Tests	Skipped	Failures	Errors	Time
1921	0 :zzz:	0 :x:	0 :fire:	1m 36s :stopwatch:

[rhfogh]

Looking good, but a quick discussion needed.

Two changes here, near as I can see:

• change readonly to readOnly . Fine. I can do that in the mxcubeqt part

• Get rid of definitions in schema, and replace with enum tag. No objection - the definitions are complex and tricky. Just one question: Doe the web interface make use of the value_dict? Currently all the pulldowns have the displayed label and the underlying value the same, but we might want to have those differ in some case.

Anyway, once we agree on this one, do you want me to make a new PR where I expand this to make the same changes in query_collection_strategy as in query_pre_strategy_params, and rebase it on the current tip (and make sure I adapt the qt version to it, which I need to do anyway). If you prefer I can leave it to you, of course.

[jbflo]

• Yes the UI library does not recognize readonly but readOnly

• Again value_dict break the UI I read the documentation and it seen value_dict is not a valid key. so enum is to be use.

Hope they are not a big breaking to the qt.

I also will need to add some Changes to the uiSchema ditct cause it does not work in the Web UI .

You can Please push your Changes to this Branch if you like , so won't need to create another PR. If they are Related to the Schemas and UISchema.

[rhfogh]

OK, without value_dict there is no way of setting a pulldown where the visible labels are different from the values returned. So far we are not using that, so it is not too big a deal. I guess that means we should simply get rid of value_dict, which we can do, and find another way of transforming from the visible label to a desired value if we ever need it. The UI schema will be more interesting - here there might well be harder to find a way to get the kind of control over the generated UI that we have currently in Qt.

I have no pending changes, but there is a recent merge in mxcubecore that means that the jb-rasmus-gphl branch will need to be rebased on develop before the PR can be merged. I do not think there should be any clashes, but there are some changes in GphlWorkflow not too far away from yours. Anyway, I leave that to you.