REST API Schema-Intent Konzept in opengever.core umsetzen

[lukasgraf]

Harvest: Projekt - Umsetzung Neues User Interface GEVER 2019/2020 - Entwicklung

Der Vorschlag in #5968 (comment) soll in Zukunft in plone.restapi umgesetzt werden.

Wir werden dazu in plone.restapi den Vorschlag machen, dies wie beschrieben zu implementieren. Da dies aber eine relativ fundamentale Anpassung ist, ist damit zu rechnen dass noch einiger Diskussionsbedarf besteht, und die Umsetzung nicht in nächster Zeit erfolgen kann.

Daher wollen wir die Umsetzung dieses Konzeptes vorerst in opengever.core prototypen. Es soll dazu das Konzept wie beschrieben umgesetzt werden, aber ohne Änderungen in plone.restapi vorzunehmen, sondern indem die nötigen Services in GEVER entsprechend überschrieben und angepasst werden.

Folgende Anpassungen sollen gemacht werden:

Weitere Aufruf-Syntax für @sources, @querysources und @vocabularies einführen

Für diese drei Endpoints soll eine neue Aufruf-Syntax eingeführt werden, welche die Add-Semantik wiederspiegelt:

(Siehe Vorschlag im referenzierten Ticket).

Die Endpoints müssen also überschrieben und so umgebaut werden, dass sie entweder 1 oder 2 Pfad-Parameter akzeptieren.

• 1 Parameter: Der parameter ist field_name. Dies impliziert edit intent
• 2 Parameter: Die Parameter sind portal_type und field_name, in dieser Reihenfolge. Dies impliziert add intent

Abhängig von der Aufruf-Syntax soll das Schema, von dem die Source, Querysource oder Vocabulary geholt wird, unterschiedlich bestimmt werden:

• edit - es soll der portal_type des context ausgelesen werden
• add - es soll der portal_type Pfad-Parameter verwendet werden

Über den portal_type wird dann die FTI geholt, und darüber das Schema, etc.. (muss voraussichtlich nicht angepasst werden).

Neuen endpoint @schema einführen

• Soll möglichst viel von der Implementierung von @types/(portal_type) aus plone.restapi erben

• Soll aber nur das serialisieren von Schemas anbieten, nicht das auflisten von existierenden / addable types

• Im Gegensatz zu @types/(portal_type) soll es aber zwei Formen des Aufrufs geben:

Intent: edit

Intent: add

• Bei der Serialisierung des Schemas soll dann der Intent erhalten bleiben, wenn Vocabulary-like URLs konstruiert werden:
  • Bei add soll auf (container)/@sources/(portal_type)/(field_name) verlinkt werden
  • Bei edit soll auf (context)/@sources/(field_name) verlinkt werden
    (analog für @vocabularies und @querysources)

Voraussichtlich werden folgende Arbeiten nötig sein:

• @sources, @querysources und @vocabularies endpoints überschreiben
• Sicherstellen dass diese Endpoints auch auf dem IPloneSiteRoot verfügbar sind (dann aber nur mit add Intent verwendbar)
• Neuen @schema endpoint registrieren (für IPloneSiteRoot und IContentish)
• Die Logik für die Schema-Generierung aus plone.restapi für den @schema endpoint wiederverwenden, aber anpassen. Dazu werden vermutlich einige Funktionen aus plone.restapi.types.utils kopiert, gewrapped oder monkey-patched werden müssen.

[lukasgraf]

Schätzung des verbleibenden Aufwands (siehe Tasks im verlinkten Draft-PR): 3 Story Points

[njohner]

Frontend: 5 SP

• Use the schema endpoint
• Treat add and edit forms separately
• no hardcoded vocabularies

[phgross]

Das ganze müsste ja nun auch im Frontend verwendet werden. Sonst haben wir keine Aussage ob das Konzept wie gewünscht funktioniert. Ich verschiebe den Issue deshalb wieder ins Todo.

[phgross]

Dieser Issue wurde umgesetzt und wird nun im UI in allen Formularen verwendet. Funktioniert wie gewünscht.