고장 분류에 성공했을 때 어떤 기록을 했는지~form의 발송 주소가 틀렸어요~

2164 단어 Wireshark시가Django

개막사


요즘 제 취미는 Django 앱 개발입니다.
초보자에게는 1을 시도할 때 10개의 오류가 있기 때문에 완성하기 어렵다
오늘은 2021년 11월 3일로 문화제가 하루 종일 오류에 직면해 간신히 기록됐다.
자기만족 글은 Qita의 투고 테스트도 겸한다

이벤트


메뉴를 만드는 자동화 프로그램, 메뉴를 만들 때
ModelForm의 save () 방법은 무엇을 해도 효과가 없습니다.
다른 한편, 서명할 때 사용하는 사용자의save () 방법은 정상적으로 작동합니다.

예약된 프로세스


1. 사용자가 로그인 상태에서 메뉴 등록 화면으로 이동
2. GET가 필요하면 템플릿으로 form을 처리합니다.as_p로 메뉴 표시 (urls.py->views.py->templates/myap/menu settings create.>)
3. 사용자가 입력하고 발송 단추를 누르면views측에서 DB로 수신하고 등록하며 페이지는 등록 완료 화면으로 이동합니다

해본 일


동일한 사례가 있는지 확인하다


키워드인'Django Modelform save는 할 수 없다'등으로 검색해 봤다.
같은 사례는 발견되지 않았다.

똑같이 잘 처리된 곳과 비교 확인하다


몇 시간이 걸렸지만 왠지 써내지 못했다.

데이터 전송 확인



나는 POST가 보낸 데이터 자체가 이상할 가능성을 고려했다.
이런 상황에서 땅고 측은 와이즈해크와 기억하고 싶어서 와이즈해크를 사용하는 것을 어떻게 확인해야 할지 모르겠다.
예상과 달리 POST에서는 데이터를 잘 보내고 있습니다.(이미지의 하반부 "testgohan3"에 있음)

수신 측 DB 확인


DB가 접수한 곳을 잠그려고 했습니다.
나는 이 사람의 보도를 참고했다.
https://qiita.com/fumihiko-hidaka/items/0f619749580da5ad9ce5

그림은 최종적으로 순조롭게 진행될 때의 그림이지만, 기본적으로runserver 터미널의 표준 오류 출력에 DB가 기록될 때의 로그가 나타납니다.(manage.py shell 구현 시에도 표시됨)
그리고 확인한 결과 이 일지는 문제가 된 곳에 나타나지 않았다.
POST에 있는 데이터가 맞는데도 DB에서 쓰기 처리가 이뤄지지 않은 것으로 드러났다는 것이다.

POST에서 특정 위치로 확인 보내기


views.py가 구멍을 확인했지만 템플릿의>확인이 많지 않습니다.
그리고formaction의 지정된 목적지와views가 수신한 목적지가 다르다는 것을 알아차려 수정했습니다

결실


formaction의 지정을views에서 받은 목적지와 같이 순조롭게 진행합니다.

총결산


일반적인 오류지만 응용 프로그램이 개발한 코드량이 많기 때문에 각종 누락이 발생하는 것도 어쩔 수 없다.
서두르지 말고 하나하나 확인하는 것이 중요하다.
(사실 아무런 실수도 하지 않는 것이 가장 좋다)

좋은 웹페이지 즐겨찾기