92-Save and display in the global request header 7/step, and add the underlying send function for multi-use case operation

Refer to the boss article: 92

Save in step

Insert picture description here


Insert picture description here


Insert picture description here
Insert picture description here


Insert picture description here


Insert picture description here

Switch between different steps to display the public request header saved by itself

Initialize and clear:

Insert picture description here

Select the request header of the target interface according to the request return value:
js reports an error when switching to an old step.
Reason: The public request header field of the old step is null. Even an empty string is not counted. The way to avoid this problem is to specify the initial default value when we add new fields afterwards
. Add an if judgment in the js code. If it is null, turn it into an empty or not run this selection Request header code.
The if judgment will only run if it is not null.

Insert picture description here
First find the place where this code should be written, that is, after our normal header is successfully converted into a dictionary, we will add it
Because what we get now is only the id of each public request header! If you want to get the real key and value, you need to get it out of the data table. This is what we did in the debugging layer of the interface library in the previous section.
But in this run_case.py, it doesn't work, because this file is a separate py file outside of the django project. We just called this file before. The salient feature of this kind of file is that if you modify the content, the project will not automatically trigger a restart, and you do not need to restart, and you can run it to achieve the latest state.
But the troublesome problem now is that since the file is outside the stray file, it currently does not have the right to get data directly from the django database.
So at present, our solution is to have two kinds:
1. We still rely on bringing these request headers at the function level when we call.
Points to consider:
How many request headers are brought in the past? When called, there are multiple step steps in the entire large use case. The number and content of request headers for each step are different. If the request header of each step is transmitted as a list , Then there may be waste. For example, the request headers used in step1 are A and B, and the request headers used in step2 are B and C, so if the list we pass is like this [[A,B] ,[B,C]] , Although the effect can be achieved, but the B is repeated once, causing huge waste.
If it is to pass all the public request headers of the entire project, this will ensure that it will not be passed repeatedly, that is, directly pass [A,B,C,D,E], and then both step1 and step2 will take what they need, so although B is not passed repeatedly, but it is obvious that D and E are wasted.
Of course, you can also write an algorithm in advance to find the union and only pass [A, B, C]. This is currently the optimal solution.
2. We do not pass it, we directly add this free file to the django project, let it obtain database permissions, and then directly check the corresponding request header. The only disadvantage of this is that this file will lose flexibility, and if you change it later, you will have to wait for the project to restart before it can take effect. This is to increase the risk of high coupling.

Grant database permissions

Insert picture description here

Add request header

Insert picture description here

Finish effect

Insert picture description here


Insert picture description here