Models Builder not recognising types from property value converter

[marc_love (Marc Love (uSkinned))]

I am working with Umbraco 16 and custom property editors. I have setup several Property Value Converters for my new property editors. They are saving JSON which should be mapped to objects. When I build my models the property type is defaulting to System.Text.Json.JsonDocument. Same code as Umbraco 13 which works as expected.

Anyone had issues with models builder and Property Value Converters in V16. Debugging the code the PropertyValueConverter should get hit when generating models however this doesnt happen.

[Luuk (Luuk Peters (Proud Nerds))]

Hi Marc,

This probably has to do with the way you define your manifest for the property editor and how you determine the IsConverter method of your PropertyValueConverter. I’ve struggled a bit with this as well and I don’t 100% full understand it yet, but I can give you a solution.

Property editors in Umbraco 16 have actually two aliasses:

• The EditorUIAlias. This determines the unique identifier of the editor on the ‘frontend’ side of the backoffice and this is a (web) component.
• The EditorAlias. This is the alias of the editor in the backend/server side. This is sort of the alias you also have in Umbraco 13.

As you can see this is split in a frontend and backend component, where the frontend component is the new one. In the Umbraco backoffice you can actually see this if you select a property editor on a data type:

Your manifest for the editor probably looks a bit like this:

export const manifests: Array<UmbExtensionManifest> = [
{
	type: 'propertyEditorUi',
	alias: "example.editor",
	name: "Example editor",
	...
	meta: {
		...
		propertyEditorSchemaAlias: "Umbraco.Plain.Json",
		...
	}
}];

The editor schema determines how data is stored and retreived from the database. The idea is that you can have multiple UI editors that use the same schema to process the data server side. The schema is also what determines the server side editor alias and in extension the property value converter.

In the about example, you’ll get the following aliasses:

• Editor UI alias: example.editor
• Editor alias: Umbraco.Plain.Json

So the issue here probably comes down to this: if you expect to use the alias property from the manifest like this:

/// <inheritdoc cref="IPropertyValueConverter.IsConverter"/>
public override bool IsConverter(IPublishedPropertyType propertyType) =>
propertyType.EditorAlias.Equals("example.editor");

It will not work. Because the editor alias will be “Umbraco.Plain.Json“.

You have two options to fix this: create your own propertyEditorSchema, but to be honest, that’s very much overkill in most situations. But nevertheless, is absolutely an option.

The second option is by far the easiest and that is just to check the editor ui alias instead of the editor alias like this:

/// <inheritdoc cref="IPropertyValueConverter.IsConverter"/>
public override bool IsConverter(IPublishedPropertyType propertyType) =>
propertyType.EditorUiAlias.Equals("example.editor");

Just a small warning though: I’ve talked with a few HQ members and some insist that you should not do this, while others do it themselves in their blogs. So to me it’s still a bit unclear if it’s bad practice. I can say though that this works perfectly fine in all cases I used this in.

[marc_love (Marc Love (uSkinned))]

Problem solved. Thanks for taking the time to explain this. Curious why HQ would be against this approach. Cant see any reason why it would be discouraged. Would be good if someone from HQ could add to this and explain.

[sebastiaan (Sebastiaan Janssen ⚓)]

I didn’t know it was discouraged, but I can easily guess why that would be: the alias can change very easily and since it’s not strongly typed, you probably won’t noticed until it’s too late.

[marc_love (Marc Love (uSkinned))]

Okay, thanks Seb.

[JasonElkin]

I think the docs need looking at for this, as they’re not clear (perhaps plain wrong).

I’m one of those people that are against doing it this way - this isn’t how property editors supposed to work in Bellissima.

If you are only defining propertyEditorUi then you are only defining half of a property editor - the UI.

In Bellissima, property editor UIs are just “views” for a property editor. A property editor’s UI can be replaced, or perhaps multiple different UIs offered for a single property editor, without changing the data structure (schema) of the property editor itself. The relationship between Property Editors and Property Editor UIs is one-to-many.

Consider a property editor for a location that stores this string: 51.235249,-2.297804. The UI for that could be a map, or two text boxes - but the schema for both of those UIs would be exactly the same, and so would my property value converter.

@Luuk

It will not work. Because the editor alias will be “Umbraco.Plain.Json“.

Exactly. Let me ask a question - is “Umbraco.Plain.Json” the alias of your property editor?

If not, why does the IPublishedPropertyType API say it is?

You haven’t actually defined the EditorAlias until you’ve registered a propertyEditorSchema - that’s how you define a schema for the data your property editor will store, and guarantee that both the UI and Property Value Converter will work together.

i.e. the propertyEditorSchema defines the “one” in the one-to-many relationship between property editors and their UIs.

@Luuk

/// <inheritdoc cref="IPropertyValueConverter.IsConverter"/>
public override bool IsConverter(IPublishedPropertyType propertyType) =>
propertyType.EditorUiAlias.Equals("example.editor");

This works because any given UI will, of course, only work with a certain schema - but you’re using the wrong API to determine the relationship between a property value converter and its property value.

What this breaks is the premise of the propertyEditorUi extension point. The idea with separating the concerns in Bellissima is that I should just be able to register a bit of JS and change only the editor UI. If I want to change the UI for your property editor I will need to roll my own PropertyValueConveter - whether I actually need to or not.

[Luuk (Luuk Peters (Proud Nerds))]

Architecturally I agree with you that this is the idea. However, I think there is a disconnect with real life. I have a lot of property editors where it’s perfectly fine to just store JSON and I can use the Umbraco.Plain.Json schema. But, what I want in the cache (what the property value converter provides) can be different per editor. Creating schema’s is not trivial and takes some work. So maybe it’s not correct compared to what’s intended, but it saves me a LOT of time.

I’ll discuss this in the documentation team. I put the docs for the property value converters and schema’s on my name so I’ll try to update them with the best practices. Maybe it’s ok to document that using the editor UI is possible but to use it cautiousy. Or maybe it should be discouraged. I don’t know yet. The opinions so far have been ambiguous. For instance, Kenn actually wrote in his blog to use the editor UI, but I’ve had Andy saying that you shouldn’t use it.

[JasonElkin]

@Luuk

Creating schema’s is not trivial and takes some work.

Then I think a discussion needs to be had about making that easier, it shouldn’t be complicated - especially if it’s going to put devs off doing it right and breaks the separation of concerns between UI and Schema.

I daresay that Kenn is wrong in that post.