-
Notifications
You must be signed in to change notification settings - Fork 33
Make UmbracoPropertyAttribute constructor for ValueResolver overridable #117
Comments
Very interesting question. I'm wondering if this could actually fall into the realms of being an Umbraco Property Value Converter? which raises the question, at what point do we recommend PVC's over VR's? It feels to me like if all you wanna do is change the type coming from UmbracoProperty, this could be when we suggest PVC's, although within Umbraco, these are global and can't be declared on a per mapping basis. I wonder though if within the MNTP PVC you can't detect what the type requested in the conversion is, and if it's just IPublishedContent then do a .FirstOrDefault on the list? I do mix the use of PVC's when using Ditto, but I've never really given it thought on when to recommend them over VR's. Wadda you think? |
A custom PVC makes sense. It gets the value in the format that you want it, at the correct part of the pipeline. I agree that ValueResolvers are more appropriate when you have no (or little) control over the PVC. The only downside I recall is that the code to replace it can be a pain in the backside. But I haven't tried it recently, (it might have been improved?) With regards to adding an overloaded constructor to |
@leekelleher I'm undecided, as it could open it up to abuse, depending on where we say you should draw the line. If we are in agreement that the PVC should be the right place, I don't think this issue is a strong enough argument to say open it up yet so I'd be tempted to leave it until a more compelling one comes along? |
My gut feeling is, if it's coming from a single umbraco property, then UmbracoPropertyAttribute along with PVC's should be used. VR's should be used if the value is calculated, or resolved from multiple locations, or a non-umbraco location? In these scenarios, there should be no need to inherit the UmbracoPropertyAttribute/Resovler. |
@jamiepollock What happens in this case if you add a TypeConverterAtrribute assigning the DittoPickerConverter to the property? If any TypeConvrters are used Ditto will check to see if you are expecting a single generic TypeParam and return that instead of an enumerable collection. It also does the reverse. This should solve your issue without the need for extra code. |
@JimBobSquarePants - @jamiepollock mentions on his original form post about using a custom TypeConverter, he wants to get the single IPublishedContent prior to that. Although this does suggest that a post-conversion-handler could be used? So many options! |
@leekelleher The question begs then.. @jamiepollock what extra behaviour is required in your converter that DittoPickerConverter doesn't already offer? It should handle converting to any Enumerable or single item from any of the built in pickers. Yeah So many options! |
Hey gents, thanks for the open discussion on this matter. Looking at the original use case, I wouldn't want anything implemented which could be open to abuse. @JimBobSquarePants I guess there isn't anything a DittoPickerConverter couldn't do, that's the desired behaviour I'm looking for. My only question is how do I use that? |
@jamiepollock Are you able to share the logic of your original custom
TypeConverter? Might be able to advise based on that.
|
The code above is a general TypeConverter when dealing with multiple items. This code is based on stuff that predates custom Value Resolvers. |
That answer looks sound to me. Great work guys 👍 |
I'm gonna close this one off. @mattbrailsford I agree about the PVC usage. |
Hey all,
As discussed on the forum, It'd be nice reuse the functionality of UmbracoPropertyAttribute when using writing new value resolvers. For example converting an existing property into a different value (eg.
IEnumerable<IPublishedContent>
to a singleIPublishContent
.As this isn't already in the core, Lee outlined this line would need to change.
Thanks,
Jamie
The text was updated successfully, but these errors were encountered: