Argument validation with attributes and Ninject interceptor

1. Introduction

It is a common practice to validate function arguments before running actual code. Usually validation looks like that:

There is nothing wrong with this code, however we have to repeat this piece of code in every function. Of course we could create some helper class for argument validation and call approperiate validation function before launching rest of the code

However I was searching for more universal way for argument validation. That is why, I decided to try function interceptors and attributes.

2. Creating validation attributes

Let’s start for creating base attribute

In the next step let’s create specialized attribute for “not null” validation. This argument may look this way:

3. Using IInterceptor interface

That was an easy part, now it’s necessary to somehow intercept function execution and run attribute validation.In .NET there is no build-in mechanism to do that,that is why I’ll use extension for Ninject – Ninject Interception. First of all we have to add to our project three dll’s

  • Ninject
  • Ninject.Extensions.Interception
  • Ninject.Extensions.Interception.LinFu

You can easily add them using NuGet. Having all necessary files added to solution,let’s create function interceptor – ValidaitionInterceptor.

As You can see ValidationInterceptor implements interface IInterceptorwhich belongs to Ninject.Extensions.Interception. This interface has one method Intercept which is called before function from registered component is called. In this function I iterate over all function attributes of type ArgumentValidationAttribute and call ValidateArgument function. If validation passess function invocation.Proceed() is called, which continues execution of original function.

4. Example of usage

In order to take advantage of benefits of function interceptors, we have to resolve objects from Ninject container. First of all I’ll create some examplorary classes

In the next step I’ll create simple wrapper for Ninject container and register CarRepository in Kernel

Please, notice that registration of CarRepository was used with option Intercept().With(). Thanks to this configuration,everytime we call method from CarRepository, Intercept method from ValidaitionInterceptor will be called first. Now, it is time to use our repository,we could do that this way

Argument entity in method Update from interface IRepository was decorated with NotNull, that is why our validation mechanism should throw exception.
CallingValidationInInterceptor
Argument validation

5. Validation of return value

Using IInterceptor we could go one step further and also validate return value of method. In order to do that, we have to slightly modify Intercept method in ValidaitionInterceptor class.

We also have to change attribute usage of ArgumentValidationAttribute to

Now, we can decorate function GetAll with NotNullattribute

Since this moment, everytime function GetAll returns null, the ArgumentNullException will be thrown.

6. Drawbacks

Unfortunately using attributes for argument validation have some drawbacks. First of all, argument validation is based on function interceptors, and as I mentioned before only function, which are in objects, which are resolved from IoC container can be intercepted. What is more, interceptors allow us to intercept only functions marked as virtual or inhirited from interface. Source code for this post can be found here

Argument validation with attributes and Ninject interceptor

Extjs 4.1.1 – validatable grid

In this post I will present a simple plugin to Ext.panel.Grid which displays validation errors on a grid. The validation mechanism is based on the model validation – useful feature of Extjs framework. Let’s start from creating a simple model:

As we can see, this model has a validation field where we can define a validation mechanism for every field in our model. In this example the lastname field is required, I use build in Extjs validator of the presence type. More build-in validation types might be found here. Of course, it is possible to define custom validation types, simple example can be found on StackoverflowHaving defined model validation, let’s create ValidatableGridplugin. The main function of ValidatableGrid plugin is function called validate which is attached to grid component. This function looks this way;

This function iterates through every model in grid’s store and runs validation method. As a result, we get a validationResult object which holds information about errors of model. This object has a function isValid which returns true if there is no errors or false otherwise. Having checked the model, we have to show errors on the grid. In order to do that, we have to find a cell, in which invalid field is displayed using getCellByPosition function. In the last step, we only have to modify CSS classes of cell. That is why, I added x-form-invalid-field class to show red line in cell and also data-errorqtip class to show validation error tooltip. The entire listing looks this way;

here is example of usage;

and the result
validatable grid
Source code for this post can be found here

Extjs 4.1.1 – validatable grid

Windows Phone – wyświetlanie błędów walidacji

Kilka miesięcy temu w tym poście przedstawiałem różne sposoby walidacji jakie są dostępne na platformie Silverlight. Jako, że ostatnio mam więcej czasu aby pisać jakieś proste aplikacje pod Windows Phonem potrzebowałem mechanizmu walidacji działającego pod tą platformą. Według MSDN-u wszystkie metody walidacji przedstawione we wspomnianym wcześniej poście powinny działać. Niestety po przerzuceniu mechanizmu z Silverlighta na Windows Phona okazało się, że błędy walidacji nie zostają wyświetlone na interfejsie. Po przeszukaniu kilku for oraz blogów dowiedziałem się, że przyczyną takiego stanu rzeczy jest brak obsługi reakcji na błędy w templacie TextBoxów (i innych elementów typu input). Zatem aby wyświetlić błędy walidacji, pozostaje nam zmodyfikować istniejący template TextBox-a. Zacznijmy od wyciągnięcia standardowego templatu TextBox-a z Windows Phona. W tym celu możemy użyć aplikacji Expression Blend. Otwórzmy w niej jakikolwiek projekt typu Windows Phone Application, w którym na kontrolce mamy naniesionego Textboxa. W moim przypadku, po wczytaniu projektu do Blenda ekran wygląda w następujący sposób
blend
Następnie zaznaczamy w Blendzie TextBox-a i z opcji znajdujących się w lewym górnym rogu aktualnej zakładki wybieramy TextBox->Edit Template-> Edit Copy.
BlendTemplateExtraction
W oknie, które się pojawi klikamy OK. Następnie możemy przejść do widoku XAML-a, w sekcji phone:PhoneApplicationPage.Resources powinien pojawić się nam nowy styl wyglądający w ten sposób

W ten oto sposób udało nam się wydobyć domyślny styl oraz template TextBoxa w Windows Phonie. W kolejnym kroku musimy zmodyfikować ten template w taki sposób, aby zaczął reagować na zmiany stanu walidacji. Zacznijmy od sprawdzenia jakie stany wizualne może obsługiwać TextBox. W tym celu musimy przeglądnąć metadane TextBoxa – możemy to zrobić klikając PPM na klasie TextBox-a i wybierając Go To Definition. Naszym oczom powinno ukazać się coś takiego.
validationstates
Widzimy, że klasa TextBox jest opatrzona atrybutami TemplateVisualState, nas interesują najbardziej trzy z tych atrybutów:

  • [TemplateVisualState(GroupName = “ValidationStates”, Name = “Valid”)]
  • [TemplateVisualState(GroupName = “ValidationStates”, Name = “InvalidFocused”)]
  • [TemplateVisualState(GroupName = “ValidationStates”, Name = “InvalidUnfocused”)]

Mówią nam one, że w przypadku gdy wystąpią błędy walidacji nasza kontrolka przechodzi w stan InvalidFocused lub InvalidUnfocused. Natomiast, w przypadku gdy nie ma błędów znajduje się ona w stanie Valid. Analizując kod domyślnego templatu TextBoxa widzimy, że stany z grupy ValidationStates nie są obsługiwane – czas zatem to zmienić. Po pierwsze do templatu musimy dorzucić elementy, które będą wyświetlały błędy walidacji. Zmieńmy zatem opakowujący wszystko element Grid na StackPanel, a następnie dodajmy element typu TextBlock oraz Border. Elementy wyświetlające błędy walidacji musimy umieścić w jednym kontenerze z elementami odpowiadającymi za wyświetlanie tekstu. Zatem musimy je opakować w Grida. Po zastosowaniu powyższych wskazówek nasz template będzie wyglądał w następujący sposób

Dodanie elementów wyświetlających błędy to nie wszystko, musimy jeszcze określić kiedy nasze elementy mają być widoczne. W chwili obecnej ich właściwość Visibility jest ustawiona na Collapsed. Zatem elementy te nie będą widoczne, jak również nie będą zajmowały miejsca na interfejsie. Jak już wcześniej wspomniałem kontrolka TextBoxa w przypadku wystąpienia błędów walidacji przejdzie do stanów InvalidFocused lub InvalidUnfocused. Pozostaje nam zatem zareagować na przejście kontrolki w te stany i odpowiednio zmodyfikować właściwość Visibility bordera oraz textblocka. W tym celu posłużymy się VisualStateManagerem oraz animacjami. Do naszego templatu dodajmy następujący wpis

W ten oto sposób zdefiniwaliśmy w XAML-u grupę (VisualStateGroup ) o nazwie ValidationStates – zauważmy, że nazwa grupy jest taka sama jak nazwa grupy z atrybutów klasy TextBox. Dodaliśmy również trzy stany wizualne (VisualState), których nazwy również odpowiadają nazwą zdefiniowanym w atrubytach klasy TextBox. Od tej chwili gdy kontrolka TextBoxa będzie posiadała błędy walidacji, zostanie odpalona animacja zmieniająca właściwość Visibility bordera “ValidationBorder” oraz TextBlocka “ValidationMessage” na Visible. Ostatecznie cały gotowy template będzie wyglądał w następujący sposób

Tak natomiast przedstawiają się błędy walidacji wyświetlone na TextBoxach
wyświetlanie błędów walidacji

Windows Phone – wyświetlanie błędów walidacji