ValueResolvers vs TypeConverters about umbraco-ditto HOT 15 CLOSED

from umbraco-ditto.

I know what you mean, but...

For me ValueResolvers have the job of resolving a value which could be from
anywhere and could be strongly typed already. Case in point, the umbraco
property value resolver could resolve basic types, as well as strongly
types if any value converters happen to be registered, but its job is
that, fetch a value for me.

With TypeConverters the job is to take a resolved value, and convert it to
something else. So say you didn't write the value resolver and you wanted
to change the type to something else, or if you have a value resolver, but
on one instance, you want the value to be something different, in these
cases you'd use a type converter.

As Lee says, I don't think there is anything wrong with a value resolver
doing some value conversion if its relevant to the value resolution ie,
there is no point resolving a basic value type if you are always then going
have to use a type converter to then make it into something meaningful
(this was the whole debate in the the current content attribute PR)

Matt
On 25 Jun 2015 11:38 pm, "Lee Kelleher" [email protected] wrote:

In my mind...

a ValueResolver would get the value (from somewhere; Umbraco property,
dictionary, wherever)

a TypeConverter would convert from one type to another, e.g. from a string
to a complex object; an int to a string, etc.

I think part of the confusion comes from wanting to keep attribute
decorations to a minimum, so a ValueResolver might also handle the
type-conversion.

We're not forcing developers to use ValueResolvers, if they prefer
TypeConverters, they can still do that - nothing has changed there.

—
Reply to this email directly or view it on GitHub
#97 (comment)
.

from umbraco-ditto.

Thanks guys, it's good to clarify this.

a ValueResolver would get the value (from somewhere; Umbraco property,
dictionary, wherever)

a TypeConverter would convert from one type to another, e.g. from a string
to a complex object; an int to a string, etc.

I think we should be very careful documenting this or we will end up in a situation where developers are hacking around trying to do complex conversion within the resolvers.

I think part of the confusion comes from wanting to keep attribute
decorations to a minimum, so a ValueResolver might also handle the
type-conversion.

and

As Lee says, I don't think there is anything wrong with a value resolver
doing some value conversion if its relevant to the value resolution ie,
there is no point resolving a basic value type if you are always then going
have to use a type converter to then make it into something meaningful.

But that's the issue exactly - It shouldn't be converting anything. We have a tool already built into the NET framework that is designed entirely for conversion. The TypeConverter can take the raw value be it json, xml, a csv or whatever and convert it into a strong typed model - all with one attribute declared once on a class.

I guess I worry that we are going to fall foul of what Umbraco suffers from. Too many ways to do one thing. That can lead to a project that becomes a nightmare to support, liable to misuse and wrongful blame.

from umbraco-ditto.

But that's the issue exactly - It shouldn't be converting anything. We have a tool already built into the NET framework that is designed entirely for conversion. The TypeConverter can take the raw value be it json, xml, a csv or whatever and convert it into a strong typed model - all with one attribute declared once on a class.

Yes, it can handle the conversion, but ONLY if you have a value already, and if you don't have a value, then you need to use a value resolver (if it can't naturally be gleaned by Ditto).

So what would you do in this scenario? Are you saying if you write a value resolver, you should resolve to some non structured format and then you'd HAVE to use a TypeConverter to convert it into something meaningful?

What is wrong with a value resolver resolving a strong type that is meaningful 99% of the time? and then using a TypeConverter for the remaining 1% to convert it into something else? This is how I see these working.

from umbraco-ditto.

What is wrong with a value resolver resolving a strong type that is meaningful 99% of the time? and then using a TypeConverter for the remaining 1% to convert it into something else? This is how I see these working.

I guess I need to understand where these values are coming from if not from whatever value GetPropertyValue or GetDictionaryValue yields. If either of those methods can give me anything then its a TypeConverter if required. That's the workflow within the extension anyway.

from umbraco-ditto.

I guess that's the thing, the value can come from anywhere, including locations outside of Umbraco. It's just that Umbraco will likely hold some contextual information for retrieving that value.

If you want to see where I am going with ValueResovlers then have a look at DitFlo for an example https://github.com/mattbrailsford/umbraco-ditflo/tree/master/Src/DitFlo.Web/App_Code/Ditto/ValueResolvers

from umbraco-ditto.

@JimBobSquarePants I'm not sure what you mean here?

If either of those methods can give me anything then its a TypeConverter if required. That's the workflow within the extension anyway.

from umbraco-ditto.

Ditflo is definitely on my list of things to do...

I mean that the methods within PublishedContentExtensions are clearly named with their roles in mind.

• GetRawValue
• GetTypedValue

They don't do what they say they do now if conversion is taking place within ValueResolvers.

from umbraco-ditto.

Sure, but what constitutes a RawValue? So a raw value can't be strongly typed? In that case we should disable all value converters registered in umbraco and just return raw string values. If the logic of the value resolver contains some conversion to give a generally meaningful "raw value" what's the issue? It's raw value is just a complex objet. If you ask for it to be converted into a different model type using a TypeConverter then within GetTypedValue it will get converted again as you would expect.

I'm really struggling to see what your argument is? Can you give me an example of a bad vs good value resolver? And where using a TypeConverter should be used instead of a ValueResovler that fetches a value and does a bit of conversion?

from umbraco-ditto.

A raw value would be any value that you return from Umbraco without third party conversion.

Any activity that takes place involving conversion both from PropertyValueConverters and TypeConverters takes place within GetTypedValue.

So good value resolvers examples would be the first two that were built in. UmbracoPropertyValueResolver and UmbracoDictionaryValueResolver.

A bad example would be anything that combines multiple objects into a new model or performs conversion out-with the functionality built into Umbraco. Anything that parses xml, json etc shouldn't be in a resolver since the xml, json string etc would be the raw value.

Combining multiple objects shouldn't even take place in a TypeConverter, that's what controllers are for.

from umbraco-ditto.

Any activity that takes place involving conversion both from PropertyValueConverters and TypeConverters takes place within GetTypedValue.

This isn't true, if you have an umbraco PropertyValueConverter registered, it will perform the conversion as part of GetRawValue so the raw value it returns is the strongly typed, converted model.

I see what you are getting at, but I think these rules are come from a standard MVC approach saying this is how things should be done, but this is not the role of Ditto to enforce that. In reality, I just don't think we have to be that strict.

As far as Ditto is concerned a Value Resolver GETs a value from somewhere, anywhere, of any type, and a Type Converter takes an EXISTING value and converts it into another.

Maybe we need to review what the GetRawValue / GetTypedValue methods are named to save confusion? GetResolvedValue / GetConvertedValue?

from umbraco-ditto.

Side note about GetRawValue... this was my bad, a misnomer. During the initial development of the, what is now ValueResolvers, it was renamed from GetUmbracoValue. (I couldn't think of a better name at the time). +1 on renaming it to GetResolvedValue.

from umbraco-ditto.

@JimBobSquarePants Cutting to the chase... what do you propose?

from umbraco-ditto.

Ok coke...

I'd vote for changing the names to that, it makes much more sense now.

As long as we document this kind of stuff well we should be ok then, thanks for humouring me. 😄

from umbraco-ditto.

💯 about documentation! I think a lot of this discussion will help the direction of it.

With my last reply, I wasn't sure whether you were going to suggest we revert/remove various parts of the ValueResolver(s)? ☺️

from umbraco-ditto.