Hi @SirAbhi13 -- Hope all is well.

This PR demonstrates a change in behavior in request.POST which as discussed last week we must avoid. With the tests passing it shows the need to add more tests for the current behavior.

Say I submit a form-data request with two parts, the second one being some JSON. I may have an request that looks something like this:

curl --location 'http://127.0.0.1:8000/polls/test/' \
--form 'name="David"' \
--form 'JSON="{\"menu\": {
    \"header\": \"SVG Viewer\",
    \"items\": [
        {\"id\": \"Open\"},
        {\"id\": \"Help\"},
        {\"id\": \"About\", \"label\": \"About Adobe CVG Viewer...\"}
    ]
}}";type=application/json'

Before this patch, request.POST is this. Here the "JSON" part is a str in the QueryDict.

<QueryDict: {
    'name': ['David'], 
    'JSON': ['{"menu": {\n    "header": "SVG Viewer",\n    "items": [\n        {"id": "Open"},\n        {"id": "Help"},\n        {"id": "About", "label": "About Adobe CVG Viewer..."}\n    ]\n}}']
}>

With this patch it becomes a dict. This would break current projects as they will be relying on the JSON part being a str and parsing it in their project. However, with this patch they would get a dict which can't be parsed again.

<QueryDict: {
    'name': ['David'], 
    'JSON': [{'menu': {'header': 'SVG Viewer', 'items': [{'id': 'Open'}, {'id': 'Help'}, {'id': 'About', 'label': 'About Adobe CVG Viewer...'}]}}]
}>

Hi David,
Thank you for the review. I will look more into this behaviour and the existing tests before changing the existing behaviour, will update this PR with the appropriate changes soon and with more test coverage.

before changing the existing behaviour

This is the concern. We want to add more tests to make sure the existing behaviour doesn't change.

The new functionality can then be introduced with the new names.

changes soon

Super. 👍 Looking forward to seeing your progress. I'd like to see something soon as time is going by quickly.

Hi @smithdc1, hope all has been well.
I came up with this logic to preserve the previous logic of request.POST. But I could use some help in checking if this is the correct way of moving forward, currently the tests in admin are failing, and I could use some help coming up with a way to move past them.

I have been working to the add the user interface of the custom parser along with this and will add those changes once we have figured out the method to address this issue, it stems from RequestFactory from what i can see in the errors.

I thought about changing the tuple that is returned in multipart itself but it would change the behaviour too much. 🤔

Hi @smithdc1,
In the latest commit I have added the logic which allows users to add their own parsers so as to parse their own requests.
I still need to add tests but I wanted a review of this design before moving forward. There's still the issue of failing tests due to the logic added in the previous commit which I can use some help in eliminating the bug. A review would be appreciated.

If the mentors approve the this design, I can add tests too.

Closing due to inactivity.