Fix the bug of not decoding nested Array of Object

[chocoford]

Fix the problem that Multipart-kit could not decode nested Array of Object mentioned in #67.

[chocoford]

The situation is more complicated than I thought before.

[chocoford]

With this PR, multipart-kit can decode form-data like below.

struct Formdata: Decodable, Equatable {
    struct NestedFormdata: Decodable, Equatable {
        struct AnotherNestedFormdata: Decodable, Equatable {
            let int: Int
            let string: String
            let strings: [String]
        }
        let int: String
        let string: Int
        let strings: [String]
        let anotherNestedFormdata: AnotherNestedFormdata
        let anotherNestedFormdataList: [AnotherNestedFormdata]
    }
    let nestedFormdata: [NestedFormdata]
}

Fixed the bug that when it comes to form-data containing arrays of objects of more than one properties, Multipart-kit then decodes it with same object's properties split into different objects(or keyed in code).

But form-data still lacks the ability to express complex nested structures. For example, when it comes to structure like below:

struct Formdata: Content {
    struct NestedFormdata: Content {
        let strings: [String]
    }
    let nestedFormdata: [NestedFormdata]
}

it cannot distinguish

Formdata(nestedFormdata: [
            .init(strings: ["1", "2"]),
            .init(strings: ["3", "4"])
        ])

from

Formdata(nestedFormdata: [
            .init(strings: ["1", "2", "3", "4"]),
        ])

(let me know if I am wrong)

[siemensikkema]

@chocoford I'll need to get into the details at a later point when I have more time but with regards to form-data not being able to distinguish between the 2 scenarios you mention it seems we'd need to introduce numbered keys. Do you know off-hand if that conflicts with any part of the spec?

[chocoford]

@chocoford I'll need to get into the details at a later point when I have more time but with regards to form-data not being able to distinguish between the 2 scenarios you mention it seems we'd need to introduce numbered keys. Do you know off-hand if that conflicts with any part of the spec?

I found Specifying array keys is optional in HTML. If you do not specify the keys, the array gets filled in the order the elements appear in the form. in PHP Documentation

So far, I haven't found any information about that from the rfc specifications.

[siemensikkema]

It seems to me like we shouldn't try to guess which element of an array a part belongs to but rather require an index except for maybe the last part of the name. So nestedFormdata[0][strings][] for example. And we should change the encoder to match that (but there just output indexes for all).

[siemensikkema]

Suggested change

[siemensikkema]

Suggested change

[chocoford]

It seems to me like we shouldn't try to guess which element of an array a part belongs to but rather require an index except for maybe the last part of the name.

That is a great idea.
Actually when form-data brings any array of objects(in-array-objects) which contains just one property, the distinguish problem exists.
If all in-array-objects containing multiple properties, the problem mentioned will no longer exist.

So, we have two options: allow or disallow optional indices for non-last keys.
If allowed, we must be able to detect if there is an in-array-object only has one property and give warnings.

[chocoford]

So far, I've allowed optional index in non-last part.

[siemensikkema]

@chocoford hi! Apologies for the long hiatus. As you can see in #70 I have been busy rethinking the Codable implementation as the existing one isn't as correct as I'd like. I'm pretty happy with how that turned out. However, it would make this PR hard to adapt.
So I've taken the liberty of drafting another PR (#71) that believe adds what we've discussed here, including your thorough unit tests! Would you be ok that we use that one in favor of your PR? (Of course you'll get your well-deserved credits!)
Do you see any issues with my implementation?

[chocoford]

@siemensikkema It doesn't matter, as long as the problem can be solved. So far, I hadn't seen any issues. The redesign is great by the way.