DotVVM v18.104.22.168 Release NotesRelease Date: 2019-04-13 // about 3 years ago
TL;DR; There are some new minor features. The most important point is Validation - EnforceClientFormat , which may break some existing code if it is using
DateTimeor nullable numberic type in view model.
🆕 New features
We have added caching interface
IDotvvmCacheAdapterthat provides access to built-in caching mechanism on Asp.Net Core or OWIN that reflect memory usage on your server.
ValueBindingExpression.CreateThisBindingis now cached, so it's invocation should be quite cheap.
When you want to create binding at runtime you can now use a helper method
DotvvmBindingCacheHelper.CreateCachedBindingthat makes sure that the binding is not recreated every time. Creation of bindings is usually time-consuming, so it should not be done on every request. (more info in PRs #672 and #664)
By the way, we have also (hopefully) improved the error messages when something fails with binding. When an error page is displayed for a binding-related exception, there is a new tab Binding that shows some information about the binding (data context, type, ...). Let us know what you think about that and what could be improved.
ValidationErrorFactory.CreateValidationResult<T>(ValidationContext validationContext, ...)
Overload that does not require explicit
Session cookies are SameSite
This was sometimes the case before. It means that postbacks won't work in third-party
iframes (so your application should be safe from clickjacking).
Validation - EnforceClientFormat
💥 This part is a fix and unfortunately a breaking change at the same time. In older versions, DotVVM did not validate that DateTime and numeric fields were valid on the client-side and sent null to the server in that case. It could be enabled by
EnforceClientFormatAttribute, but nobody really did. It is now by default enabled on nullable numeric types, DateTime, and DateTime?, so it enables validation in cases where it was disabled previously. While this has a potential to "fix" existing code as not validating the input is likely a bug, it may also break some code that relied on that behavior. Please make sure that all your views using nullable DateTime and numerics work as expected. (more info in PR #666)
🚚 For example, suppose you had a
dot:TextBoxbound to a property of type
int?. The problem is that when you paste value like
"asd", it will write a null value into the property because
"asd"is not a valid numeric value. The solution for this problem was applying
EnforceClientFormatAttributeto the property in your view model. Now, you don't have to do that anymore. If you use that attribute somewhere, you can safely remove it.
Repeater control initialization
We have change a bit how the Repeater initialization works. Controls with templates have to initialize the control tree before it is used by command invocation and HTML rendering and when this initialization is dependent on data from view model, it has to be done twice on postbacks - once before command invocation and then before rendering since the command may have changed the data. In older version Repeater have not done that in all cases, because it's quite time-consuming. Unfortunately, in some cases, it broke some code, so we are now re-initializing it two times, but only in case the data is actually changed. (more info in #653)
Unique id generation for nested trees
⚡️ If you were creating controls at runtime, you may know that before adding more child controls into the newly create control has to be added to the control tree. The reason was, that the mechanism that generates unique ID (for control command and
Postback.Update) did not work correctly when entire subtree was added at once. From this version, this should work correctly, so you can initialize entire subtrees at once. (more info in #668)
It should now get precedence over the
Events.Clickhandler. (more info in #630)
_ Fixed in DotVVM 22.214.171.124 _
👻 When you installed
Microsoft.Extensions.DependencyInjection2.1.0 or higher in your application and used
DotvvmAuthenticationHelper.ApplyRedirectResponse, this method was throwing an exception with a message that ServiceProvider had been disposed.
netstandard assembly loading on .NET Framework 4.7.1+
_ Fixed in DotVVM 126.96.36.199 _
DotVVM View compilation on .NET471+ was not able to load netstandard assembly.