UmbracoPropertyDataValue Resolver about umbraco-ditto HOT 14 CLOSED

I guess it's just what is the use case? I know you mention nuPickers, but what makes the resolved property value inadequate? such that you would then want to work direct with the raw value?

from umbraco-ditto.

I guess it's to intentionally bypass the associated IPropertyValueConverter.

The issue (for me) on nuPickers is that we're all talking about introducing more code to workaround having a Picker object. Ultimately they want to use Picker.AsPublishedContent() to get the nodeIds, then get the IPublishedContent, then call .As<T>() to map the POCO.

I can't help by think that using content.GetProperty("alias").DataValue would be a more efficient way, (with less code/assemblies).

from umbraco-ditto.

I've found that using a type converter that inherits the formally named DittoMultiNodeTreePicker converter worked perfectly for nuPickers. What advantage does this approach have over that?

from umbraco-ditto.

I can't help but think this sounds like a failing in nuPickers though not giving it's values in a meaningful way, and that by accessing the raw value, it's effectively like using internal methods. We should really try and stick to using public apis for each 3rd party package as you could end up with a tangled mess.

Maybe I need to know more about why there is a Picker object and why it's not good enough as a value to be converted.

from umbraco-ditto.

@JimBobSquarePants yup, nuPickers TypeConverter that supplies a core Ditto TypeConverter with IPublishedContent works well :)

@mattbrailsford A Picker object (as returned by a PropertyValueConverter) contains lots of useful infomation about the saved value and the data-type, and is consistent across all the nuPicker property editors, it also abstracts away the actual storage mechanism (CSV, JSON, XML Relations) although the raw value can still be returned. What's the failing in nuPickers in your opinion ?

from umbraco-ditto.

Just to add, a Picker object contains everything required to be converted, but that would mean coupling Ditto and nuPickers.

from umbraco-ditto.

@Hendy I don't know, I'm just saying, if there is a need to access the raw value, instead of the one the developer exposes via the umbraco value converter, why is that?

from umbraco-ditto.

@mattbrailsford but the developer doesn't have to access the raw value ? besides, it's available on the Picker obj with .ToString() or .SavedValue should it be needed.

from umbraco-ditto.

@Hendy ask @leekelleher, he's the one suggesting the need for it :)

from umbraco-ditto.

To be clear, I'm not suggesting that nuPickers (or the Picker object) is doing anything wrong.

The point I'm trying to get to is for us to not have to write additional code/assemblies for every custom property-editor that wants to support Ditto/TypeConverters.

Lets say that we've implemented this UmbracoPropertyDataValue attribute/resolver, we'd have a decorated POCO property like this...

[UmbracoPropertyDataValue("myPropertyAlias")]
[TypeConverter(typeof(DittoPickerConverter))]
public IEnumerable<MyCustomPoco> MyPropertyName { get; set; }

That would get the raw value (DataValue), then pass it to the type-converter - job done.

The alternative, (as being suggested on nuPickers issue #100), is to have a separate assembly, (called whatever "Our.Umbraco.Ditto.nuPickers" something), that contains a single class (inherited TypeConverter) with minimal code, that would achieve this...

[UmbracoPropertyValue("myPropertyAlias")]
[TypeConverter(typeof(nuPickerConverter))]
public IEnumerable<MyCustomPoco> MyPropertyName { get; set; }

The advantage of this is that nuPickerConverter would be typed using the Picker class object, (I can see the appeal of this) ... but is it worth the overhead of a separate assembly + VS project + Git repo + AppVeyor set-up + etc?

from umbraco-ditto.

@leekelleher if we could do away with all that overhead that'd be great, but wouldn't that mean that Ditto would have to understand how to parse the raw value of 3rd party property-editors ?

(there would be issues with nuPickers and a RelationsOnly SaveFormat, as there isn't a raw value !)

from umbraco-ditto.

@leekelleher I get what you mean, but I just don't think we should be relying on a prop editors raw DB value. To me, that value should be classed as "internal" and thus shouldn't be relied upon. Take NestedContent for example, in some of the updates we have done, we have wildly changed the raw saved value, yet the value from the value converter is the same, because this is our public API. By dealing with the raw value, yes you've removed an explicit dependency with nuPickers, but I think you've gained a much worse hidden dependency, because you'll only find out when you come to use it, not when you come to compile it.

from umbraco-ditto.

@Hendy @mattbrailsford - totally valid points! (Hence why I wanted to start this side of the discussion 😈)

from umbraco-ditto.

Closing this one for now... it may be revisited in future, but I agree with comments about using the value's "public API".

from umbraco-ditto.