|Number of votes:||1|
When the EPiServer property system was rewritten in the EPiServer CMS 5 release properties was split into two parts: one core class that handled the data and one class responsible for creating UI: s. One question I got several times, specially after the CMS 5 release was how to implement input validation on the server. Should it end up in the core property or in the property control? Using the built in asp.NET validators it’s pretty simple setting up different validators in the property control that can validate both on the client as well as on the server.
But what if you have code setting the property’s value that does not use the property’s property control but rather set the value of the property directly, or perhaps through a custom UI on the web site? The simple solution is of course to do input validation in the property’s Value setter. This might have some side effects though.
EPiServers built in PropertyDocumentUrl and PropertyImageUrl properties have validation that the value of the property is an URL that actually points to an existing file within the EPiServer CMS file system. When working with the improved on page edit functionality in EPiServer CMS 6 R2 we decided to move file validation from the property controls to the actual properties. This had some side effects though. When importing data for instance, the property value was actually set before the import of the referenced file which would cause an exception.
There already exists an interface called IPropertyPreferLoadData in the EPiServer.Core namespace. This is a marker interface that informs users of the property that it prefers using the LoadData method when initializing the property instead of setting the data through the Value property. In CMS 6 this is used when loading data from the database but unfortunately not when importing/mirroring data. This has been changed in EPiServer CMS 6 R2 so that it works the same way for page loads and data imports. This makes is possible to add validation in the Value property setter but bypassing the validation (if desired) in the LoadData method.
PropertyUrl implements logic that calls an empty, virtual method called ValidateUri in the Value setter. PropertyDocumentUrl and PropertyImageUrl now inherits from the abstract class PropertyFileUrl. PropertyFileUrl implements IPropertyPreferLoadData and adds logic to the ValidateUri method. In short, this is how the classes looks like:
Another scenario where this would be an useful approach is where data validation rules might change. For instance, you want to create a property where the user should set an integer. The min and max value of the integer is defined by property settings. With this scenario data that was valid yesterday is not longer valid since the property settings might change. In EPiServer CMS 6 this would work fine if validation was implemented in the property control but when implemented in the property would throw an exception when loading the property from the database if the stored data was no longer valid. With the same approach as the property URL classes this should now work fine when implemented in the core property class.