How to create custom field type that imitates Object (JSON) behavior

Using v5 KeystoneJS

Aforementioned, I’ve come across a scenario which requires me to create an Object of Integer type fields as:

    fields: {
        user: {
            type: Relationship,
            ref: 'User'
        },
        parameters: {
           focus: {type: Integer, defaultValue: 0},
           smoothness: {type: Integer, defaultValue: 0},
           legal: {type: Integer, defaultValue: 0},
           braking: {type: Integer, defaultValue: 0},
           distraction: {type: Integer, defaultValue: 0},
           rash_driving: {type: Integer, defaultValue: 0},
        },
    },

For now, we are resorting on creating a Relationship between the models (yes, we had to break this object into a whole model of its own!).

Now, I found this issue however since sit only imitates Text behaviour, it didn’t work out for us. I’ve been trying to understand the official documentation as well but can’t seem to work it out as well due to lack of any examples online.

Can anyone help?

[molomby]

I’ve just seen this issue. It touches on some interesting conversations we’ve been having lately around encoding standard field types within JSON.

Basically the idea is that, once the JSON DB adapter (#1177) is done, field types will have specific JSON encode/decode functionality baked in. This should let Keystone create “JSON-ready” object from any list item. If we also borrow some machinery from the JSON field type (#315) it opens up some interesting possibilities, like:

• Storing a subset (or multiple subsets) of lists fields in a JSON blob, rather than regular DB columns
• Nesting fields (as per the original question)
• Storing a “history” of item changes in a JSON array, within the item record
• Importing/exporting to JSON

The first point in particular is interesting I think as it would let us app developers do Mongo-like prototyping of their list schemas, then easily transition to a proper relational schema once their models had settled down. Keystone could do this transparently and maybe by default – so if, for example, you added a field to a list without adding a column to the relevant table, your values would be stored in a _otherFields JSON column until you updated your DB structure.

[sambhav2612]

@Vultraz actually there’s more to this model than I wrote, it has more fields and we need distinction between these parameters from all other fields in the model henceforth we went with the 2 level hierarchy