fix: get schemata defined in the context #1796
Conversation
This comment was marked as resolved.
This comment was marked as resolved.
✅ Deploy Preview for plone-restapi canceled.
|
Co-authored-by: Steve Piercy <web@stevepiercy.com>
|
@jenkins-plone-org please run jobs |
|
@jenkins-plone-org please run jobs |
| if fti.id == context.portal_type: | ||
| additional_schemata = tuple(getAdditionalSchemata(context=context)) | ||
| else: | ||
| additional_schemata = tuple(getAdditionalSchemata(portal_type=fti.id)) |
There was a problem hiding this comment.
@mamico Can you help me understand the logic here? What is the scenario where we can't or shouldn't pass the context?
There was a problem hiding this comment.
@davisagli thanks for asking for clarification and putting me doubts...
The api is called to know the schema at the creation of a new CT or to know the schema at the modification of a content. In the first case I expected it to always be called from the root of the portal (but I'm wrong), in the second case it is called from the context of the object, and it would be useful to request the schema by passing the context.
So currently it is called (ie by Volto) as:
/++api++/@types/Document creation in the root
/++api++/folder/@types/Document creation in a folder
/++api++/folder/doc1/@types/Document modification of /folder/doc1
... but also ...
/++api++/folder/doc1/@types/Document to the creation of a new document inside doc1
... here the modification I proposed behaves incorrectly (doc1.portal_type is equal to Document but the correct schema is the generic schema, not the contextual).
I am putting the PR back in draft because it needs to be rethought in some way.
Suggestions?
There was a problem hiding this comment.
@mamico It's important to get the schema for new content items in the context of its container, because some vocabularies might be context-dependent. (i.e. a list of keywords that depends on what section you are in)
So maybe we need a parameter so that the schema can be requested with or without context-dependent behaviors. Then they could be included by default, but the add form could request it without this.
There was a problem hiding this comment.
@davisagli Your position is clear, and I absolutely agree with you. Do you have any suggestions for the parameter name to use? Something like .../@types/Document?contextual=1 ?
get schemata for behaviors defined in the context. ie using a
plone.dexterity.behavior.DexterityBehaviorAssignableadaptersee https://github.com/collective/collective.instancebehavior/