TypeConverter

[Hendy]

convert from Picker to model property return type
see: https://gist.github.com/Hendy/da5d8a67e1711d195c9a

[Hendy]

Had to park this as realised the TypeConverter has a reference to Ditto - @leekelleher don't suppose you have any thoughts as to where best to put a TypeConverter that needs a reference to both Ditto and nuPickers ?

[leekelleher]

@Hendy With your original gist post, we do have some built-in TypeConverters with Ditto, (in next release, v0.7.0)

https://github.com/leekelleher/umbraco-ditto/tree/develop/src/Our.Umbraco.Ditto/ComponentModel/TypeConverters

As for something that overlays both Ditto and nuPickers, it would need to be a separate project/assembly... I face the same issue when developing custom Courier data-resolvers for property-editors (e.g. Archetype, Mortar).

[Hendy]

Would be good to have a base TypeConverter that will convert from IPublishedContent to a custom POCO (as in gist above) and have a nuPicker TypeConverter inherit from this. The nuPicker TypeConverter would then just need to supply this base class with Picker.AsPublishedContent()

[leekelleher]

@Hendy we do have DittoContentPickerConverter, (in the next version, v0.7.0), that can accept an IPublishedContent - could that be reused?

[Hendy]

@leekelleher yep 👍 have just been discussing this with @JimBobSquarePants on Skype. Seems that the only reason I wrote the IPublishedContent -> POCO TC in the gist above is that I didn't pay any attention to the DittoMultiNodeTreePickerConverter due to it's name ! I think a better name would be "DittoPickerConverter".

[JimBobSquarePants]

💯 On the name. It's a misnomer now.

[Hendy]

@leekelleher @JimBobSquarePants using a "DittoPickerConverter" (or whatever it is to be called) as a base class for a nuPickerTypeConverter would be ideal, but instead of nuPickers referencing DItto (which would be awkward for the Umbraco package) where should we put such TypeConverters that reference both Ditto & 3rd parties ? as a separate project - Our.Umbraco.Ditto.Something ? /cc @mattbrailsford @robertjf

[leekelleher]

How's about "Our.Umbraco.Ditto.Collab"? Whatever it's called, it could be set up as a VS project in the main Ditto repo... or a totally separate Git repo?

[robertjf]

Is this package meant to contain TypeConverters relating to Ditto only? Should we have a more generic project name to reference other projects as well?

[robertjf]

Our.Umbraco.TypeConverters perhaps?

[Hendy]

Would they be used outside of DItto ? (certainly a reference to Ditto would be required + any other 3rd party property-editors) I imagine this would be a single (optional) dll, most likely of relevance to people using VS.NET, so could be an independent NuGet package (no Umbraco package).

[Hendy]

If it's unlikely to be used outside of Ditto (can you think of a use-case where they might be ?) then being a part of the Ditto repo makes sense (assuming of course that it's easy to create a separate NuGet package, as wouldn't want to force 3rd party installs with Ditto /cc @Jeavon)

IMHO, the word Collab seems a bit vague - call them what they are :) Our.Umbraco.Ditto.TypeConverters ?

[leekelleher]

Yeah, "Collab" sounds like a dumping ground, which isn't the problem you're trying to solve. Taking a step back, thinking about the problem at hand... isn't the `Picker` object the concern here? Random thought... if the property-value converter is disabled/bypassed, then the raw data could be passed to the TypeConverter (in Ditto). Another thought... in latest Ditto (v0.7.0), we've introduced a concept of "Value Resolvers" to get the raw data to be converted. Maybe we have one to get the Umbraco property's `DataValue`?

[Hendy]

@leekelleher not sure what the "Value Resolvers" are but I'm sure you wouldn't want Ditto to know how to parse all the nuPicker SaveFormats - the goal I think is to decouple Ditto and 3rd party.

[mattbrailsford]

I'm wondering if these things should be kept as individual side projects of each package, kinda like what happens with courier resolvers at the moment. To have one large VS project that has dependencies on all the third party packages that need converters will make for one big dependency chain no? I was thinking each package dev would just create an add on DLL if they want to provide DITTO support?

[JimBobSquarePants]

Separate projects and nuget packages for each one most definitely but maybe a single location to store them? El Packeeros.

[leekelleher]

@Hendy - ah yes, SaveFormat, the Achilles heel ;-)

[Hendy]

@mattbrailsford arh yes, I hadn't considered all those dependencies, and that's the issue I was hoping to avoid ! So separate NuGet packages for each Ditto + 3rd party combo.

A nuPickers TypeConverter deriving from a core Ditto one would only be a few lines of code, so setting up the build process would be the bulk of the work !

Would a single repo building multiple NuGet packages would be preferable ? /cc @Jeavon if so, then Our.Umbraco.Ditto.ThirdParty assembly / namespaces ?

[Jeavon]

@Hendy yes a single repo makes sense with a project for each package. Only thing to consider is that all the packages will version together if in a single repo, I don't think it's a problem. We have the same setup with Optimus and all it's providers...