Repository navigation
Conversation
Documentation build overview
217 files changed ·
|
|
@pnicolli damn, I kept thinking about it and went through all the current widgets that we have, and it's harder than I thought... it definitelly needs more love. Only alone the use case for public forms is a thing we have to address. |
pnicolli
left a comment
pnicolli
left a comment
There was a problem hiding this comment.
Yeah it needs more love, but I think starting with a good documentation of what we want to achieve is a good starting point to actually achieve consistent behavior in widgets and better code quality. It might be challenging and we might end up adapting these docs to actually match what we need, but I think it's a good starting point.
| A field is the form-level representation of one piece of content data. | ||
| It has a name, a current value, validation state, and schema metadata. | ||
| In a content form, a field usually comes from a Plone schema property. | ||
| For example, `title`, `description`, `effective`, and `is_folderish` are fields when the form renders them as editable metadata. |
There was a problem hiding this comment.
I'm not sure we should include is_folderish in this example
| ## Adapter | ||
|
|
||
| An adapter is a wrapper that turns a control into a widget. | ||
| It maps the form field contract to the control contract. | ||
| This is the right place to translate names, normalize values, and convert validation metadata into the shape expected by the control. | ||
|
|
||
| For example, a boolean widget can adapt a checkbox control by mapping `value` to `isSelected` and by mapping `onChange(value)` to the checkbox's selected state callback. |
There was a problem hiding this comment.
I don't understand how this is different from the Widget definition.
There was a problem hiding this comment.
I thought that would make sense, but if we standardize and further fully specify what is a widget-able component and what is not, we might get away only with one. It also came from the fact of having "half way threre" components in @plone/components that might need an adapter... but it's true that we could make them behave fully with our canonical widget definition specs, and that's it.
|
|
||
| ```tsx | ||
| function BooleanWidget(props: FormWidgetProps<boolean>) { | ||
| return null; |
There was a problem hiding this comment.
If what you wanted here is to avoid focusing on what is the code of the function, I would just write the function signature, like
function BooleanWidget(props: FormWidgetProps<boolean>)or something like this
function BooleanWidget(props: FormWidgetProps<boolean>) {
// ...
}with return null I was like "wth" for a moment and I can only assume I won't be the only one
|
|
||
| Registering those controls directly makes the form generator depend on many incompatible prop conventions. | ||
| That weakens the registry because the registry can no longer promise what a widget receives or returns. | ||
| Adapters keep the boundary explicit. |
There was a problem hiding this comment.
Why? But my question might come from the fact that I didn't understand adapters, see my other question above
| Seven forms are schema-driven. | ||
| A content schema describes metadata fields, and the CMS UI turns those fields into interactive form elements. | ||
| This process is intentionally split into several concepts: fields, controls, widgets, and adapters. | ||
| The distinction matters because not every visual input component can be registered directly as a CMS widget. |
Co-authored-by: Steve Piercy <web@stevepiercy.com>
|
Moving it to plone/aurora#97 |
3 participants
Supersedes: #8237 and #8247