ASP.NET Web Forms

Czytając oficjalny trening kit do egzaminu 70-515 natrafiłem na taki tekst: “With view state, data is stored within controls on a page. For example, if a user types an address into a TextBox and view state is enabled, the address will remain in the TextBox between requests.”. Skoro takie zdania padają w zalecanym podręczniku, nic dziwnego, że łatwo pogubić się w tym jak ASP.NET Web Forms próbuje radzić sobie z naturalną dla HTTP bezstanowością… ;)

Ustawienie właściwości MaxLength w kontrolce asp:TextBox pozwala na ograniczenie ilości znaków jakie użytkownik może wprowadzić w pole tekstowe. Ustawienie to działa jednak jedynie gdy właściwość TextMode kontrolki ustawiona jest na SingleLine lub Password (nie zadziała w przypadku opcji MultiLine). Dzieje się tak ponieważ w dwóch pierwszych przypadkach TextBox renderowany jest jako element HTML input type=“text”, który może posiadać atrybut maxlength informujący przeglądarkę o konieczności ograniczenia ilości znaków. Gdy ustawi się tryb wielowierszowy, TextBox renderowany jest jako element textarea (który nie obsługuje atrybutu maxlenght).

Istnieje kilka powodów, dla których nie powinno się umieszczać aplikacji ASP.NET w środowisku produkcyjnym z ustawieniem <compilation debug=”true”/> (czytaj…). Wbrew pozorom prędkość wykonywania instrukcji kodu po stronie serwera nie stanowi bardzo istotnego problemu. Inaczej jednak wygląda sytuacja po stronie klienta - gdy nasza aplikacja korzysta z javascriptowej biblioteki Microsoft AJAX Framework. Wówczas ustawienie Release/Debug1 ma ogromny wpływ na szybkość wykonywania kodu aplikacji!

Załóżmy, że z jakiegoś powodu musisz umieścić w obszarze kontrolki UpdatePanel funkcję JavaScript, której kod będzie się zmieniał przy każdej aktualizacji panelu. Funkcja ta ma być wywoływana w odpowiedzi na zdarzenie onclick jakiegoś elementu, który znajduję się poza UpdatePanelem…

Gdy kontrolka znajdująca się w UpdatePanelu wykonuje asynchroniczny postback skutkujący błędem po stronie serwera, użytkownik zostaje poinformowany o problemie przez komunikat JavaScript. Treść tego komunikatu jest taka sama jak właściwość Message wyjątku. Alert ukaże się jedynie wtedy, gdy witryna nie korzysta z przekierowania w przypadku błędu lub, gdy właściwość AllowCustomErrorsRedirect kontrolki ScriptManager jest ustawiona na false.

ASP.NET AJAX oferuje łatwy w użyciu i efektywny mechanizm wywołań metod na serwerze z poziomu JavaScript. Mowa o Page Methods. Ponieważ są one statyczne1 nie możesz w kodzie takiej metody użyć dostępu do właściwości Page.Session. Nie oznacza to jednak, że musisz zrezygnować z wykorzystania sesji. Wystarczy, że zamiast Page.Session skorzystasz z HttpContext.Current.Session.

Przy przenoszeniu aplikacji z maszyny testowej na środowisko produkcyjne zawsze pojawiają się jakieś problemy (zwykle drobne - jak w opisywanym przypadku). Czas leci a w myślach “WTF?”…

Podczas korzystania z kontrolki CheckBox i ustawiania jej po stronie klienta jako nieaktywnej, natchnąłem się na problem, który (przeoczony) może sporo namieszać w pracy aplikacji. Otóż jeśli CheckBox jest zaznaczony i zablokujesz go ustawiając właściwość disabled w JavaScript to po postbacku zobaczysz, że właściwość Checked == false!