We have solved the problem of extracting data from various interfaces in previous chapters. The task of this section is to pass these to the back end and save them successfully.

Open P_apis. HTML and find the ts_save() function we left unfinished last time:

The reason we didn’t write this function directly was because we suddenly realized that we didn’t get the interface ID, so when we passed it to the back end, we had no idea which interface it was. So we ended up writing the ts_show() function, which permanently keeps the current interface ID in a small tag after opening the shell. Our ts_save() function can then retrieve the current interface ID from the permanent small tag.

So get the id now:

Then write a request to send the data to the back end:

Ulr I defined as: /Api_save/

Ts_api_body = ts_api_body = ts_api_body = ts_api_body = ts_API_body Strings and arrays, we can only send them as strings, so we want to convert the two arrays to strings at the end:

Add the code to convert an array to a string as follows:

Then write urls.py:

Write the background function again:

Let’s think about what this background function does:

  1. Get all the data from the front end

  2. save

  3. The saved copy is displayed

The code is as follows:

Def Api_save(request): GET['ts_method'] ts_url = request.GET['ts_url'] ts_host = request request.GET['ts_host'] ts_header = request.GET['ts_header'] ts_body_method = request.GET['ts_body_method'] ts_api_body = Request.GET[' ts_API_body '] # save data db_api.objects.filter (id=api_id). Update (API_method = ts_method, API_URL = ts_URL, api_header = ts_header, api_host = ts_host, body_method = ts_body_method, API = ts_API_body) # return HttpResponse('success')Copy the code

The next step is to start the service, refresh the page, and then test the save of each encoding format to see if there are any errors, etc. I said before, we test development tools, do not have bugs, or it would be too embarrassing, because there is no special test schedule, so we should be careful and comprehensive test every step. Of course, because of the internal tools, there is no need to pursue various exception input exception handling situations.

After adequate testing, no errors were found. So let’s just keep going.

In the current case, although the new data is successfully saved in the background after the user clicks the save button, the debugger layer is still open. Function (ret){} : function (ret){} : function (ret){} :

Refresh the page to try again, found that you can click save to close the shell layer, more in line with the use of habits.

Here’s a question to consider:

Every time we hide the cartridge layer, the content saved in each input box of the cartridge layer is not actually cleared, so the next time we click the debug button of another interface, it will still open this cartridge layer, so the content of each input box is actually the content of the previous interface. This is equivalent to the consequences of not clearing the cache, and similar bugs have appeared in many of our apps.

Some students will say that in our ts_show() function, it is already clear that it is time to load the new interface data into each input field of the shell. The data from the previous interface will be overwritten.

That’s true, of course, in an ideal world.

However, the following two cases are not easy to say:

  1. When the network is slow, the user opens it and sees the old data first, then two seconds later, the new data is loaded and replaced. It’s easy to make people doubt their eyes, or debug things incorrectly.

  2. When the new data fails to load, no replacement succeeds, but the user may not know the failure because he still sees the data of the previous interface, thinking that the old data is the data of the current interface. If he accidentally hits the save button at this point, the save button will actually change the old data to the new interface. The data of the real new interface is lost forever.

So in order for all of the above risk scenarios to come true, it is necessary to create a function that clears the cache, clear_ts_api(). This function cleans up the input fields of the debug shell each time it is run.

When to run, it is called every time the user opens it, at the very beginning of the ts_show() function.

Let’s start with a new function:

Then internally start to write clean code:

This function is actually not very simple, after cleaning up the simple part, we will continue to deal with the complex request body encoding part.

Before doing this, we need to add ids to some of the tags in the HTML section of the code for better control:

Add id to None so that when a new interface opens, it defaults to None instead of saving the subpage status of the previous interface and writing the corresponding initialization code. Click ()

Then delete the request body tr for the two table classes we wrote earlier for debugging:

Note, however, that we must leave a blank line, otherwise we will trigger the bug of the third party table plugin

Change to the following:

Then there is the code we need to initialize. To facilitate the initial call, we still need to add ids to both tBodies:

Then we write the code:

Here we use force to change its child content to an empty TR row with two TD columns in it.

Then, immediately after, five multi-line text boxes are cleared:

Finally, there is a return body text box, which we also empty, so that the return value of the previous interface is not mistaken for the return value of the current interface:

So let’s add id to it:

Code:

Finally, we call clear_ts_api in the ts_show() function:

Then refresh the page to test:

We found a bug:

This is the third party table plugin, although we have managed to get it to keep a blank line, but it seems that the blank line is not displaying correctly:

The modify and delete buttons are not even displayed. Even if we click the add new parameter button, it just copies the first line, and multiple incorrect lines appear:

The problem with this is that the third party plug-in wants to display correctly, not just the HTML, but eventually it needs to run its JS functions to render it correctly.

This function is the part we introduced earlier:

These two functions are not in effect because we did not add them when we ran clear_ts_API (), and they were originally run when the entire interface library page was entered. If we wanted to change the contents of tbody, tr, TD, etc., then we would have to re-run them. So we need to run both functions again at the end of the clear_ts_api() function:

Now let’s refresh the page and see again: the effect is already working.

Don’t delete a single line, otherwise you won’t be able to add new parameters. There are a lot of ways to avoid this, but you really need to switch to form-data and x-www… Instead of deleting the first line, edit the first line or add many lines first. Of course, in case the first line is deleted by mistake, just save/cancel and reopen it.

This is the end of this lesson, because there are many codes written in the form of live broadcast. If there are any bugs, please give feedback in time, and we will fix them in the next lesson.