Property editor composition rewrite for Umbraco 17 #7685
Conversation
…ir architecture, and configuration settings
…ce clarity on architecture and custom implementations
…s on Property Editor settings, configuration, and validation handling for improved clarity and usability
AndyButland
left a comment
AndyButland
left a comment
There was a problem hiding this comment.
This is great @Luuk1983. I just had a few comments on the wording in a few places where I though it was a either a little repetitive or vague, but mostly seems to me you and your AI helper have done a really good job here. I don't see any factual issues at all, so just have a few tidying up suggestions.
| {% endhint %} | ||
|
|
||
| The Property Editor Schema is server code, written in C#. This handles the storage of a Property Editor and defines _Server Side Validation_ and _Property Value Converters_. | ||
| The Property Editor Schema runs server-side (in C# code) and has the final say on whether data is valid to commit to the database. The Property Editor UI is where the user inputs their data. You can have client-side validation, but the Property Editor Schema has the final say. This means that if there is a mismatch in client-side and server-side validation, the server-side validation can reject data that the client-side validation considers valid. |
There was a problem hiding this comment.
This paragraph uses "has the final say" twice, so I think could be made more succinct (or at least use a different way of saying it the second time).
| * [Property Editor Schema](property-editor-schema.md) | ||
| * [Property Editor UI](property-editor-ui.md) | ||
| ### Separation of Concerns | ||
| This architectural separation provides flexibility. Multiple UIs can use the same schema with different visual presentations. The same schema can serve different purposes through different UI implementations. The schema ensures data integrity while you can swap the UI component without migration or data loss. |
There was a problem hiding this comment.
Maybe this is saying the same thing twice and we only need one of the sentences? "Multiple UIs can use the same schema with different visual presentations. The same schema can serve different purposes through different UI implementations."
| * Each Property Editor can have multiple Property Editor UIs. | ||
| * Both a Property Editor Schema and Property Editor UI can define the Settings used for their configuration. | ||
| ### Data Types: Configuring Property Editors | ||
| A Data Type is a configured instance of a Property Editor that you create in the Umbraco backoffice. A Data Type is the entity that you add to your content pages for editors to work with. With Data Types, you can create one or multiple instances of the same Property Editor with different settings. When users are editing content, the Data Type knows what UI element to display and what settings to use. When content is saved, the Data Type knows how it needs to process this data. This is because the Data Type knows the alias of the Property Editor UI, the alias of the Property Editor Schema, and the settings set on the Data Type instance. |
There was a problem hiding this comment.
"A Data Type is the entity that you add to your content pages for editors to work with" Maybe this could be tightened up, to e.g. "A Data Type is the entity that you add as a property on a Document, Media or Member types to define how for editors will manage a particular item of data."
| ## Property Editor Schema anatomy | ||
| On the server side, a Property Editor Schema is built from two collaborating components. The `DataEditor` serves as the definition and factory, while `DataValueEditor` instances perform the actual data handling work. This separation allows Umbraco to efficiently reuse schema definitions across multiple Data Type configurations. | ||
|
|
||
| The frontend needs to be able to use the schema. Depending on the use case, it might need to be registered in the Extension Registry. The following entities are covered: |
There was a problem hiding this comment.
"The frontend needs to be able to use the schema. Depending on the use case, it might need to be registered in the Extension Registry." is a little vague. Maybe you could link to other pages for more discussion on the front-end aspects?
And maybe the introduction to the diagram should be clearer, with instead of "The following entities are covered" something like "The following diagram illustrates the client and server side components involved in a property editor."
3 participants
📋 Description
This is a rework of the pages that combined describe the part that make up a Property Editor. It covers an overview page, a page about the Property Editor UI and the Property Editor Schema.
📎 Related Issues (if applicable)
Fixes #7603
✅ Contributor Checklist
I've followed the Umbraco Documentation Style Guide and can confirm that:
Product & Version (if relevant)
Umbraco 17
Deadline (if relevant)