Provide field order in JSON Schemas from @types endpoint about plone.restapi

[tisto]

We ran into that as well. We have two options:

1. Make the response return the order in the "right" order
2. Provide a "position" attribute

I'd go with 1 if possible. @lukasgraf @ebrehault opinions?

[ebrehault]

That's part of the things JSON Schema does not address (because it focuses on schemas, not on forms).

In angular2-schema-form, I have decided to use an order attribute which is an array of field ids: https://github.com/makinacorpus/angular2-schema-form#fields-presentation-and-ordering

I think it is a more solid approach than assuming the fields will be in the right order in properties.

We have a similar solution for fieldset by the way.

[davisagli]

I like choice 1 better, but some quick googling turns up a few sources saying one shouldn't rely on JSON object properties being ordered, so yeah, I guess we shouldn't.

@ebrehault I guess you mean something like this for fieldsets:

"fieldsets": [
    {
        "name": "default",
        "label": "Default",
        "fields": ["title", "description", ...]
    }
}

With fieldsets like that, do we really need a separate order?

[lukasgraf]

Yeah, exposing an API that implies that keys in JSON objects are order is something we should avoid (that is, for any order that is actually relevant to the data - controlling the order of keys with the purpose of making it convenient to read for humans (list id and title early, stable sort order) is something different).

When I used JSON schema for something else in our own projects and needed this, I went exactly with the solution that @ebrehault described (I went with field_order). Yes, it's a bit cumbersome, but it works and it avoids misuse of data structures.

So I prefer 2.

[ebrehault]

@davisagli having a separate order field is useful for forms without fieldset, but I agree having order in one case and fields in the other case is strange. So maybe we should use the same property name to order the form fields and the fieldset fields, and field_order sounds nice as proposed by @lukasgraf

[davisagli]

I would consider a form without any explicitly declared fieldsets to contain one fieldset, the default fieldset. But if you disagree and want to support listing field order both at the schema level and within fieldsets, then I agree it's good to be consistent and call it field_order in both cases.

[ebrehault]

Oh, sorry, I didn't mean I want to support field ordering at schema level and within fieldsets at the same time. I just meant schema level ordering is useful when we do not have any fieldset declared (else, schema level ordering should obviously be ignored or not allowed).
So it is pretty much equivalent to consider that the default fieldset is implicit (and consequently we must use the same property name to order fields in an explicit fieldset and in the implicit default fieldset).

[lukasgraf]

We also discussed this again at the Beethoven Sprint:

At this point, I'm leaning towards the style @davisagli outlined above:

Always include a toplevel fieldsets:

"fieldsets": [
    {
        "name": "default",
        "label": "Default",
        "fields": ["title", "description", "..."]
    },
    {
        "name": "address",
        "label": "Address",
        "fields": ["fistname", "lastname", "..."]
    }
]

No need to track field order separately, both the order of fieldsets and their individual fields would be well defined that way. If no explicit plone.autoform fieldset directives have been used, fields will end up in the default fieldset. Empty fieldsets may occur.

Field moves as indicated by plone.autoform order_before / order_after should also be processed if possible, and may therefore affect the final resulting position of fields in their respective fieldsets. So field moves would be abstracted away by the API, and only the final resulting order will be dumped.

/cc @ebrehault

[tisto]

Solved in #237