Gdy pod koniec 2013 roku zaczynałem pracę nad swoim frameworkiem, jednym z najważniejszych wyborów, które musiałem podjąć, był wybór kontrolki grida. Po przeanalizowaniu dostępnych rozwiązań, zdecydowałem się na jqGrid. Wydawał się prosty w obsłudze i miał dobre wsparcie po stronie serwerowej ASP.NET MVC (tzn. builder i model binder). Do tego był darmowy. No właśnie - tu jest problem - BYŁ. Od grudnia 2014 przestał być dostępny na licencji MIT, i z tego powodu stanąłem przed koniecznością zamiany go na coś darmowego.

To trzecia i (mam nadzieję) ostatnia część moich przygód z kontrolką daty w PizzaMVC. Tym razem musiałem naprawić problem związany z polskim zapisem daty wynikający z ewidentych błędów Microsoftu w .NET Framework. A przy okazji napisałem najdłuższy program w Javie w swoim życiu.

Bootstrap datepicker pojawił się w PizzaMVC przy okazji migracji z ASP.NET MVC 4 na 5. Ponieważ wersja 5 standarodowo korzysta z Bootstrapa, musiałem wymienić poprzednie kontrolki (pochodzące z jQuery UI) na coś kompatybilnego z Bootstrapem. Wtedy zrobiłem to pod presją czasu, wrzucając luźno pliki JS i podpinając je po linii najmniejszego oporu. Teraz przyszła pora na poprawki.

To będzie krótki post, ale cudaczność tej biblioteki naprawdę zasługuje na oddzielny wpis. Najprostszą odpowiedzią na tytułowe pytanie jest oczywiście to, że moment.js został napisany w JavaScript, a język ten nie słynie z przemyślanych rozwiązań…

Jak pisałem w poprzednim poście, celem moich ostatnich działań było oddzielenie Pizza.Mvc od Pizza.Framework. Po wydzieleniu modułu Pizza.Utils, był już tylko jeden punkt łączący te dwa moduły - przekazywanie informacji o zalogowanym użytkowniku, do NHibernatowego event handlera, który przeprowadza audyt obiektu przy jego tworzeniu bądź aktualizacji w bazie. Pierwotnie zrobiłem to w niezbyt estestyczny sposób, teraz to poprawiłem i w sumie zastanawiam się, czemu od razu nie zrobiłem dobrze.

Tym razem wpis o bieżących postępach w pracy nad Pizzą. Jedną z głównych refaktoryzacji, które planowałem już od dawna było usunięcie zależności między Pizza.Mvc a Pizza.Framework. Rozdzielenie tych modułów wymaga kilku etapów pracy, ten post jest o pierwszym z nich - wydzieleniu przestrzeni nazw Pizza.Framework.Utils do nowego assembly Pizza.Utils.dll.

Właściwie nigdy wcześniej nie zastanawiałem się nad debugowaniem kodu .NET frameworka. Zawsze chyba wychodziłem z założenia, że pewno łatwo się nie da, więc nawet nie próbowałem. Z drugiej strony, nigdy nie miałem dużej potrzeby, aby to robić, więc i nie drążyłem tematu. Ostatnio (podczas moich przygód z lokalizowaniem komunikatów walidacyjnych) działy się niezrozumiałe dla mnie rzeczy, więc chciałem się dowiedzieć co tam się właściwie dzieje i nawet mi się udało - chociaż łatwo nie było.

Gdy w 2008 czy tam 2009 roku Microsoft wynalazł wzorzec MVC ¹, firma ta jako jedną z większych zalet nowego frameworka podawała odróżniającą go od WebFormsów elastyczność i możliwość łatwej konfiguracji. (Pojechanie po innym swoim produkcie to swoją drogą jest świetny chwyt marketingowy.) Zdawałoby się zatem, że lokalizowanie standardowych komunikatów błędów powinno być banalne. No i w sumie jest, gdy już się potrafi to zrobić.

A miało być tak pięknie… Po świętach miałem zrobić proste zadanie i od razu napisać o tym krótkiego posta. No, ale nieco poległem na dość prostym zadaniu - lokalizacji aplikacji. Tzn. lokalizacja aplikacji była prosta, problemy się narodziły przy lokalizowaniu komunikatów o błędach oraz debugowaniu System.Web.Mvc.dll. Ale o tym będą inne posty, o ile wcześniej nie zwariuję.

W tym poście kontyuuję temat z poprzedniego, gdyż ostatnio wzbogaciłem swój proces generowania paczek o niezwykle istotną funkcję, a mianowicie wersjonowanie plików binarnych i paczek nugeta. Początkowo numer paczki był nadawany na podstawie release notes, zaś dllki nie były wersjonwane w ogóle. Tak oczywiście być nie może, nie tylko dlatego, że kiedyś mam zamiar wypuścić Pizzę w świat. Nawet testując paczki lokalnie, sam się nieraz gubię w tym, którą wersję testuję, czy prawidłowo się zaktualizowała, i czy zawiera pożądane zmiany. Nie da się tego stwierdzić, jeśli po każdym buildzie paczka ma ten sam numer, a dllki na stałe mają wpisane 1.0.0.0.