Evaluate JSON Schema

[tisto]

• ietf draft
• PYTHON: pythonjsonschema (laurence has a branch to work better with colander, default field)
• JAVASCRIPT: jsonschema

[tisto]

There are quite a few JS form libraries (Angular, React, etc.) out there that work with JSON schema, e.g.:

https://github.com/mozilla-services/react-jsonschema-form
http://schemaform.io/

The basic idea would be that the client application asks for "application/schema+json" via accept header and gets the JSON schema back. Endpoints could be any content object in Plone. This can be used by the client applications to render the edit form.

An alternative would be to have a specific endpoint to ask for the schema. Though, I think the first solution is more elegant.

[lukasgraf]

I agree that the first solution has a certain elegancy to it, but how about the content-creation use case? If a client application wants to add some new content of type Foo, it would need an endpoint to ask for the schema. And even if another object of that type already exists (which it might not), the client application would need to locate and ask a completely unrelated object for its type's schema, which is a pretty awkward way to go about things.

[tisto]

@lukasgraf good point. Then I guess we need to decide if we want the first solution in addition to a "factory" endpoint.

[cedricmessiant]

I'm gonna work on this subject for a customer project. I have to generate a JSONSchema from Dexterity content types so I can work on the mapping between the DX fields and the JSONSchema

[tisto]

@cedricmessiant awesome! Would you mind starting with roughly outlining the endpoint design you have in mind? Do you plan to have a single endpoint for all portal type schemas (e.g. exposing the portal_types tool via REST)?

[lukasgraf]

@tisto I believe we might possibly need both. Both vocabulary factories and default value factories / default value adapters can be dynamic and context dependent.

I also did some work recently that relates to this - automatically generating Sphinx docs that describe the schemata used by our custom content types (so I can hand that to the customer that's going to use the API). It's currently a bit hackish and in a "works for our types" sort of state, but I'll contribute back what I can once I cleaned that up. @cedricmessiant I'll drop you a line the next couple days as soon as I pushed that code.

[lukasgraf]

What could get tricky here is Plone's (resp. DX and AT's) lack of clear separation between the data model, validation and forms. So much of validation and default value generation is tied into form logic.

E.g., the default value that is being chosen and proposed when a user adds a DX content type TTW is essentially determined in z3c.form.widget.Widget.update().

If that logic ends up looking for a default value adapter, that will be an adapter that adapts context, request, form, field and widget to IValue, and could therefore potentially depend on all of those things.

---

Another thing that we might have to deal with at some point are the plone.autoform directives: Fields can be omitted, reordered, grouped / moved into fieldsets, and have individual read / write permissions. I'm not sure how much of this will be relevant to us, but here's some pointers as to how it works:

Those form hints are stored on the schema interfaces as tagged values. TGV from an individual schema interface can be retrieved with iface.queryTaggedValue(KEY). But the fun bit is getting merged tagged values that consider interface inheritance and IRO. Both plone.autoform and plone.supermodel contain several helper functions that should be useful here.

[cedricmessiant]

@tisto : My intuition is to use a single endpoint. Exposing the portal_types tool may be useful e.g. to be able to retrieve the list of portal types via the restapi.

But first, I will focus on the adapters to map zope.schema fields with jsonschema. I probably wont use the REST api in my application.

[cedricmessiant]

It's done ! (See : dea48da )

[tisto]

Done: #92