DotVVM 1.0 Beta Released

Today is a big day for DotVVM. After a year of hard work, the 1.0 release has been pushed to the official Nuget feed. Also, we have published the first version of DotVVM Pro for Visual Studio 2015 and Bootstrap for DotVVM which you can try now.

Breaking Changes

We had to do many refactorings and namespace changes to make sure the public API won't it in future. Also, we have renamed some classes and controls to shorter names. Here is the list of the most important changes:

• ValidationMessage control was renamed to Validator and its ValidatedValue property is now just Value which is much more convenient to use.

• Validate.Enabled and Validate.Target was renamed to Validation.Enabled and Validation.Target because it makes more sense.

• Instead of writing ViewModelProtection(ViewModelProtectionSettings.SignData) we now write Protect(ProtectMode.Sign). This is similar to the Bind(Direction.ServerToClient).

• The AddAttributesToRender and Render... methods in DotVVM controls has a new signature - instead of the RequestContext context parameter they now get IDotvvmRequestContext context. We decided to remove the RequestContext class completely because it didn't contain anything important and only wrapped IDotvvmRequestContext.

• The app.UseDotVVM method now requires a generic parameter which points to a class implementing the IDotvvmStartup interface. In the Configure method of this class, you should register all controls and routes which you use in the application. This is because the Visual Studio extension - when you build a DotVVM project, the extension loads the assembly on the background and executes the Configure method in this class to get a list of routes and controls. Thanks to this mechanism, we can provide IntelliSense for route names, route parameters and more. You can read more about this in the DotVVM Project Contents tutorial.

• In the DotvvmRequestContext class we had the Redirect method which had two overloads. The first did the redirect to a specified URL, the second redirected to a specific route with given parameters. Because the overloads did different things, we decided to split them into RedirectToUrl and RedirectToRoute methods which is more clear. The same applies to the RedirectPermanent method. Now we have RedirectToUrlPermanent and RedirectToRoutePermanent.

• The OnException method in ExceptionFilterAttribute was renamed to OnCommandException, because in only handles exceptions in command.