Diwebsity

KendoUI Grid control is very flexible and powerful widget to present table data. It provides us a set of useful features. All of them is described very well in Kendo Grid documentation. However there is some cases that these possibilities is not enough to fulfill our requirements.

KendoUI Grid support filters and sorting data in user interface. These filters can do some complex logic. Especially if we decide to pass them to API layer and evaluate server side. Let’s imagine that user set a complex filtering and sorting rules that helps him to manage his data. Then he move to another page and when he want to get back he have to set all filters again.

When I first try to write test for class that use directly, I found that I can’t mock database context directly using for example Moq library. That’s because this class properties isn’t virtual. After some research I found that EF6 could be set up to enable mocking [1,2]. However that is not quite what I need. I had some specific requirements:

1. I want to trace operations into database tables
2. It must work for Code First EF6 configuration
3. It should be generic solution for each database table

Po dokładnym opisaniu mechanizmu czas na przedstawienie planowanej architektury implementowanego przeze mnie rozwiązania. Warto też zdefiniować cel projektu oraz zestaw kroków, które zawiodą mnie do jego wykonania.

Zacznijmy więc od zdefiniowania funkcjonalności, które chcemy osiągnąć w projekcie. Oczywiście można założyć, że docelowo chcielibyśmy zaimplementować spójny mechanizm OWASP AppSensor w pełnym jego zakresie, z implementacją wszystkich zdefiniowanych punktów detekcji i integracji z innymi systemami. Jednak z doświadczenia wiem już, że ten sposób określania wymagań nie jest dobry, bo dość słabo motywuje do pracy i do skończenia projektu. Zamiast tego zdefiniujemy MVP naszego projektu.

Walidatory Wyróżniamy 2 rodzaje walidatorów zasobów: silne – występują wtedy, gdy każda zmiana zawartości zasobu powoduje wykrycie zmiany w walidatorze słabe – gdy wykrywanie zmian w walidatorze opiera się na danych niezależnych od wartości zasobu (np. na informacjach o czasie) Zgodnie z powyższą definicja wyróżniamy dwa rodzaje cache’a: Cache oparty na czasie Polega on na tym, że przechowywany zasób może być używany tylko przez zdefiniowany czas. Do tego celu używany jest nagłówek: Last-Modified, który wskazuje na datę ostatniej modyfikacji zasobu….

Read More Read More

Nagłówek Vary Nagłówek Vary umożliwia określenie, które elementy wiadomości (poza standardowymi: metodą, adresem i hostem) jednoznacznie identyfikują dany zasób. Jest to szczególnie przydatne podczas korzystania z mechanizmu Content negotiation. Dla przykładu odpowiedź zawierająca Vary: accept-language informuje, że nagłówek accept-language powinien być uwzględniony w kluczu obiektów cache. Może to wynikać z faktu, że nagłówek ten pozwala ustalić z klientem język wyniku zapytania, a więc dla każdego języka odpowiedź może się znacząco różnić. Nagłówek Vary może przyjmować wartości: * – oznacza, że…

Read More Read More

Zajmiemy się także metodą PATCH. Nie jest ona wprawdzie częścią standardu HTTP, jednak dość dobrze uzupełnia go w kwestii operacji częściowego aktualizowania danych. Przypomnijmy, że metoda PUT służy do zastąpienia danego zasobu, zaś POST do jego wstawienia. W sytuacji, gdy potrzebujemy zaktualizować tylko kilka właściwości rekordu, zastosujemy metodę PATCH. W treści wiadomości PATCH znajduje się ciąg informacji o tym, jakie pole i w jaki sposób zmienić. Jeżeli wskazywany zasób jeszcze nie istnieje, może on zostać utworzony, jeżeli informacje o zmianach zawierają wszelkie wymagane…

Read More Read More