Support for custom primitive types

[tomasherceg]

We've added support for registering custom primitive types.

There is one unresolved issue - the static command wasn't deserializing method arguments using converters from DotVVM.
We've introduced this, but:

1. It is a breaking change.
2. The code needs to be refactored as the argument deserialization is in DotvvmPresenter that should not depend on Newtonsoft.Json. I think it should be moved to IViewModelSerializer, or maybe added as another interface.

Also, unit tests and UI tests are missing.

[exyi]

There is one unresolved issue - the static command wasn't deserializing method arguments using converters from DotVVM

Awesome, this is the subject of #809. We will have to leave it for 5.0, since this breaks quite many things. Or maybe put it behind a feature flag.

[acizmarik]

This type can not be actually nullable. We handle those differently

[tomasherceg]

What is the problem with nullable types here? In the sample, we are using Guid? since the typed id is a reference type and can be null.

[acizmarik]

This use-case seems to work nicely with reference types. If SampleId, which is a reference type, maps to Guid? - then properties that are of type SampleId work correctly.

The problem comes when SampleId is a value type (struct). Then we can have also a nullable and non-nullable property. This can generate funny stuff like this:

[acizmarik]

We should probably add a check when generating metadata for value types so that such situation can not happen. Otherwise users should not registrate these with nullable underlying type, otherwise it can be doubled.

[tomasherceg]

Rename to UseDotvvmSerializationForStaticCommands
Add XML comment
Will be true by default in the next release
Make sure it applies also for static command response

[acizmarik]

We just discussed with @exyi that there is another potential issue - when user creates a custom primitive type and binds it into a textbox. How to treat this expression?

• We said that on client-side we would use the underlying types (which might have special formatting)
• However, expressions are generated on server from the custom type (that does not have special formatting by default)

I am not sure that this behaviour is clear or generally expected by users. What is the correct approach here?

[acizmarik]

Furthermore, format overriding is not trivial (see our textbox binding handler 😄). The easiest solution would be IMO to format based on the underlying type

[tomasherceg]

user creates a custom primitive type and binds it into a textbox
For now, I would not support this. We'd have to provide ToString(format) implementation and JS translation, and somehow extend the globalize library to support formatting.
If these types don't work with TextBox, we should throw a compilation error.

[exyi]

One more small issue - Currently, the validator skips all primitive types. I'd expect it to be validated if the custom primitive implements IValidatableObject, or if the value property has a ValidationAttribute.

[tomasherceg]

The last thing we wanted to do is to change the [CustomPrimitiveType] attribute to a marker interface. Its presence is easier to detect without the need for caching.