andrzej.net.pl » c#

ErrorProvider i focus po nieudanej walidacji

andrzej — Thu, 13 May 2010 21:59:43 +0000

Notka to bardziej – ku pamięci – niż pełnowartościowy wpis. Na co dzień programuję głównie dla weba używając ASP.NET, od czasu do czasu zdarza mi się napisać proste rzeczy w Windows Forms. Dziś przez dobre 30 minut (jeśli nie lepiej) rwałem sobie włosy z głowy zastanawiając się jakie property i w czym przestawić, żeby kontrolka ErrorProvider po zwalidowaniu TextBoxa pokazała błąd ale pozwoliła przejść dalej w formularzu (zmienić focus).

Im dłużej szukałem tym bardziej irytacja narastała. Przypadek ala „Biega, krzyczy pan Hilary: Gdzie są moje okulary?” Pamiętałem, że chodziło o coś w stylu „AllowTabChange”, „AllowFocusChaneOnError” czy inne cudo.

Najbardziej naturalne wydało mi się poszukiwanie we właściwościach samej kontrolki error provider. Oczywiście – nic bardziej mylnego :]

BlinkRate, BlinkStyle.. Nie ma nic pomocnego w rozwiązaniu mojego ogromnego, egzystencjonalnego problemu.
Później zacząłem się przyglądać właściwościom samego TextBoxa… CausingValidation! Nie.. też nie to. Wtedy przestały się odpalać zdarzenia Validating i Validated – w sumie czemu miałoby być inaczej niż mówi opis tej właściwości ;) ?

Nadal uparcie blokował się focus na TextBoxie, jeśli jego zawartość nie spełniała warunków walidacji.. a ja tylko chciałem wypelnić sobie formularz w dowolnej kolejności!

Przyszło oświecenie i zacząłem szukać we właściwościach samej formy.. Wiadomo – im bardziej czegoś się szuka tym bardziej się to ukrywa. Chyba za trzecim razem znalazłem property AutoValidate! Tak – to było to… Oklaski, owacje na stojąco, kurtyna… Zapamiętam już raczej do końca życia ;)

Oj potrafią dać w kość czasem takie głupoty. Człowiek nagle nie wie jak odpytać google’a, by coś sensownego podpowiedział, nikogo znajomego na żadnym komunikatorze. Strach i przerażenie ;)

Też zdarzają się Wam takie małe przeszkadzajki, odbierające więcej energii niż kilka godzin programowania :) ?

Nie znaleziono powiązanych wpisów.

Powiązane wpisy wygenerowane przez wtyczkę Yet Another Related Posts.

Shallow copy a deep copy – klonowanie obiektu z MemberwiseClone oraz przy użyciu serializacji

andrzej — Wed, 06 Jan 2010 22:40:53 +0000

Rozróżnia się dwie możliwości klonowania obiektów:

shallow copy – tzw. płytka kopia. Najczęściej wykonywana przy użyciu metody MemberwiseClone z klasy Object.
deep copy – tzw. głęboka, pełna kopia. Przyjrzymy się jednej z możliwości jej realizacji – wykorzystania serializacji do strumienia w pamięci.

Zapewne wszyscy wiedzą o istnieniu metody MemberwiseClone w klasie Object.
Pozwala ona na wykonanie tzw. „shallow copy”, czyli „płytkiej kopii” obiektu. Kopia taka nie radzi sobie jednak z typami referencyjnymi zagnieżdżonymi w klonowanym obiekcie. Potrafi poprawnie kopiować tylko Value Types.

Weźmy przykładową klasę Person:

public class Person
{
public string FirstName { get; set; }
public string LastName { get; set; }
public DateTime BirthDate { get; set; }
public Person Boss { get; set; }

public Person( string firstName, string lastName, DateTime birthDate )
{
this.FirstName = firstName;
this.LastName = lastName;
this.BirthDate = birthDate;
}
}

Możemy zaimplementować interfejs ICloneable dla „shallow copy” w ten sposób:

public object Clone()
{
return this.MemberwiseClone();
}

Co się jednak stanie, gdy wykonamy kopię zmiennej kowalski z poniższego przykładu?

Person jankowski = new Person("Stefan", "Jankowski", new DateTime(1977,2,25));
Person kowalski = new Person("Jan", "Kowalski", new DateTime(1980,12,4));

kowalski.Boss = jankowski;

Person kowalskiCopy = (Person)kowalski.Clone();

Debug.Write(kowalski.Boss == kowalskiCopy.Boss);

Wynik? Tak jak oczekiwaliśmy, Boss w obiekcie kowalski oraz kowalskiCopy wskazują na ten sam obiekt – jankowski.

Jak widać nie jest to idealne wyjście. Rzadko zdarza się, by obiekt zawierał wyłącznie value types. Ponadto metodę MemberwiseClone możemy wywołać tylko w klasie, do której mamy dostęp. Dlaczego? Ponieważ jest ona oznaczona jako protected w klasie Object. Oznacza to, że nie użyjemy jej, gdy chcemy sklonować typ z innej biblioteki, której źródła nie jesteśmy w stanie sami zmodyfikować implementując ICloneable.

Właśnie tutaj z pomocą przychodzi nam serializacja. Wystarczy zserializować obiekt do strumienia w pamięci i zdeserializować do innej instancji. Gotowe.

Jak z realizacją?
Nic nie stoi na przeszkodze, aby zamknąć kod w statycznej metodzie i wykorzystać typ generyczny. Dzięki temu będziemy mogli przy użyciu jednej metody serializować wszystkie typy! No – prawie wszystkie.

Należy pamiętać, że typ, który chcemy serializować:

musi być oznaczony atrybutem Serializable
wszystkie jego pola muszą być serializowalne

Jeśli klasa nie będzie spełniać powyższych wymagań, w runtime otrzymamy SerializationException.

Do naszej klasy wprowadzamy więc małą modyfikację:

[Serializable]
public class Person
{
...
}

Metoda, którą będziemy serializować nasze obiekty jest dość prosta.

W dyrektywie using tworzymy nowy MemoryStream. Następnie tworzymy instancję BinaryFormattera, informując go w konstruktorze, że będzie użyty w kontekście serializacji.
Serializujemy przekazany obiekt, przewijamy stream do początku i deserializujemy. Musimy przeprowadzić rzutowanie (Deserialize zwraca Object). Trochę kodu:

public static T CloneObject<T>( T item )
{
using ( MemoryStream ms = new MemoryStream() )
{
//instancja BinaryFormattera - informujemy go,
//ze bedzie uzyty w celu klonowania
BinaryFormatter bf = new BinaryFormatter(null,
new StreamingContext(StreamingContextStates.Clone));

//serializacja
bf.Serialize(ms, item);

//przewijamy memoryStream do poczatku
ms.Seek(0, SeekOrigin.Begin);

//deserializacja
return ( T )bf.Deserialize(ms);
}
}

To wszystko. Przykład użycia:

Person kowalskiCopy = Tools.CloneObject<Person>(kowalski);

Debug.Write(kowalski.Boss == kowalskiCopy.Boss);

Efekt wykonania tej metody? W oknie output pojawi się false. Oznacza to, że obiekt został w pełni sklonowany – łącznie z referencją do szefa.

Jest jeszcze kilka niewielkich niuansów związanych z serializacją – jak np. delegaty czy propertiesy, które nie powinny być serializowalne. To jednak materiał na odrębny, obszerny wpis.

Powiązane wpisy:

Show-hide JavaScript – proste podłączenie przy użyciu C#

Powiązane wpisy wygenerowane przez wtyczkę Yet Another Related Posts.

Visual Studio – jednoczesne debugowanie kilku projektów w solution

andrzej — Wed, 06 Jan 2010 21:45:06 +0000

Najprostsze rozwiązania często są w Visual Studio sprytnie ukryte. Takie czasem odnoszę wrażenie. Jedną z rzeczy, na które narzekałem przy debugowaniu np. WebService’ów czy aplikacji współdzielących niektóre zasoby był brak możliwości ustawienia jako „Startup” kilku projektów w ramach jednej solucji. Okazuje się jednak, że jest to banalnie proste..

Przeważnie ustawiałem jeden projekt jako startowy korzystając z opcji w menu kontekstowym na projekcie: „Set as startup project”.

Możliwe jest jednak ustawienie wielu projektów jako startowych. W tym celu należy wywołać menu kontekstowe na Solution i wybrać Properties:

Naszym oczom ukaże się okno właściwości. Wybieramy po lewej opcję Common Properties -> Startup Project.
Teraz wystarczy przełączyć je w tryb „Multiple startup projects” i wybrać akcję na tych projektach, które nas interesują:

Można ustawić projekt w trybie:

None – wiadomo ;)
Start – uruchamia z debuggerem
Start without debugging – wiadomo ;)

Także.. happy debugging! ;)

Powiązane wpisy:

The Web Application is configured to use IIS. The IIS Web server is not installed on this computer.

Powiązane wpisy wygenerowane przez wtyczkę Yet Another Related Posts.

Mutex i sprawdzanie czy aplikacja jest jedyną uruchomioną

andrzej — Mon, 04 Jan 2010 21:30:55 +0000

Uzupełniam ostatnio braki w wiedzy, dotyczące synchronizacji wątków. Gdzieś w podrozdziale dotyczącym tego tematu przykuł moją uwagę Mutex. Mutex to, obok monitorów i semaforów, jedna z „prymitywnych” metod synchronizacji. Ma jednak bardzo ciekawą właściwość, odróżniającą ją od kolegów po fachu…

Otóż co to za właściwość? Tatusiem Mutexu jest bezpośrednio windowsowy kernel a jego właścicielem może być w jednej chwili tylko jeden wątek. Wątek, który przejmuje obiekt typu Mutex na własność nie blokuje sam siebie ale musi zwolnić go przy użyciu metody ReleaseMutex. Co w tym nadzwyczajnego? Jeszcze jedna sztuczka!

Korzystając z jednego z przeciążonych konstruktorów, możemy nadać obiektowi typu Mutex nazwę. Uwaga, kurtyna w górę ;) Nazwa ta jest unikalna wśród wszystkich procesów w systemie! Otóż to, panie i panowie ;) Całe to cudeńko pozwala nam niejako udostępniać obiekt Mutex pomiędzy różnymi aplikacjami. Przeważnie użylibyśmy tej właściwości do synchronizacji dostępu tych aplikacji np. do zasobów dyskowych, sieciowych itp. Jednak jest jeszcze jedno interesujące użycie.

Do sedna. Wykorzystując konstruktor z trzema parametrami:

public Mutex(
bool initiallyOwned,
string name,
out bool createdNew
)

Możemy skonstruować sprytny kod, który pozwoli uruchomić jednocześnie tylko jedną instancję pisanej przez nas aplikacji. Przykład?

static void Main( string[] args )
{

bool isNewCreated;

System.Threading.Mutex mutex = new Mutex(true, "MUTEX_DEMO", out isNewCreated);

if ( isNewCreated )
{
Console.WriteLine("Brawo - jesteś pierwszy! ;)");
}
else
{
Console.WriteLine("Niestety! Nie byłeś pierwszy ;)");
}

Console.ReadLine();

}

W sumie jedną linijką kodu załatwiamy sprawdzenie. Być może nie jest to wyjście idealne, ale czasem może uratować trochę czasu.

Powiązane wpisy:

„throw” czy „throw exc” – czyli jak najlepiej przerzucić wyjątek wyżej

Powiązane wpisy wygenerowane przez wtyczkę Yet Another Related Posts.

Książki – co czytam. Certyfikacja – czy warto?

andrzej — Fri, 16 Oct 2009 21:52:07 +0000

Na wstępie „krótkie” wprowadzenie – opis książki, którą męczyłem przez ostatnie ładnych „kilka” dni ;)

Co uważniejsi z czytelników zauważyli malutki widget po prawej stronie – „Obecnie czytam”. Właśnie wymieniła się w niej książka. Skończyłem czytać „CLR VIA C#” Richtera, zabieram się za „VISUAL C# 2005: THE BASE CLASS LIBRARY” Balena. Z tą książką powinno pójść łatwiej i szybciej niż z Richterem (takie mam wrażenie).

CLR VIA C# jest bardzo interesującą pozycją, którą polecam każdemu. Richter w dość swoisty sposób rozebrał na części pierwsze wszystko, z czym spotykamy się na co dzień. Pierwsza część jest mocno teoretyczna – operacja na otwartym sercu .NET, czyli CLR właśnie. Ciekawostki, ogólny zarys i założenia, które zapadają w pamięć i sporo rozjaśniają. Część „Working with types” – dość ciekawa. Nie zanudza, mimo, iż opisuje rzeczy oczywiste. „Designing parts” – wspaniałe kompendium dla każdego, kto programuje współdzielone komponenty lub po prostu dąży do tego, by jego kod był zgodny ze standardem, skalowalny, bezpieczny i zoptymalizowany. 70 stron czyta się z miłym odczuciem, że nareszcie ktoś uporządkował to nad czym zawsze zastanawiałem się „czy robię to dobrze?”.

Dział „Essential types” również segreguje i porządkuje zagadnienia dotyczące rzeczy, z którymi spotykami się często. Praca z tekstem, typami enumerowanymi, tablicami, interfejsami, typami generycznymi – po lekturze staje się bardziej przewidywalna i pewna. Same przykłady są naprawdę w porządku. Prezentują często wiele aspektów poruszanego zagadnienia w przystępny sposób. Nie traktują czytelnika jako „niepełnosprytnego” wyjaśniając niepotrzebnie każdą linijkę – oby takie przykłady spotykać w każdej książce.

Sekcja „CLR Facilities” nie jest lekka ale jest niesamowicie przydatna. Świadomość istnienia i sposób działania Garbage Collectora, refleksje i operacje asynchroniczne – nie taki wilk straszny, jak go malują.

Książki tej (niemal 650 stron) nie da się przeczytać i zapamiętać wszystkiego. Nie raz jednak wracam do niej podczas codziennej pracy, utrwalając coś, co w danej chwili robię. Sama świadomość, że wiadomo gdzie zajrzeć aby uzyskać pewną podpowiedź czy wskazówkę jest komfortowa. Książka to kompendium, które zwraca uwagę na aspekty często traktowane w innych publikacjach po macoszemu lub wręcz pomijane. „Important notes” – przyciągają uwagę do pułapek, na których można się wyłożyć przy nieumiejętnym używaniu tego, co oferuje C#. Jednocześnie książkę czyta się przyjemnie. Liczne wzmianki o tym, że Microsoft (zdaniem autora) coś schrzanił i ma nadzieję, że naprawią to w następnej wersji przyprawiają o uśmiech i zwracają uwagę na to, że nikt nie jest nieomylny ;) Richter ma co prawda świra na punkcie thread safety, security, wydajności, zasięgu widoczności zmiennych, pieczętowania klas – i trochę tym zaraża ;) To w sumie jedyny zarzut do książki ;)

Jeden z przykładów, gdy sedno będzie krótsze niż wstęp ;) Po przeczytaniu „THE BCL” zastanawiam się nad połknięciem pozycji stricte „egzaminowej” i podejście do MCTS. Propozycja szefostwa i własne obserwacje to 70-536: Microsoft .NET Framework – Application Development Foundation. Ktoś z Was miał sposobność zdawać? Jak poszło? Jak się przygotowywaliście? Ile czasu Wam to zajęło? Może ktoś, tak jak ja, dopiero planuje? Czy według Was obecnie takie potwierdzenie umiejętności – poza własną satysfakcją – jest przydatne?

Zapraszam do dyskusji w komentarzach. Myślę, że pomoże to i mi rozwiać niektóre wątpliwości.
Jeśli ktoś chce podzielić się informacją o ciekawej książce (niekoniecznie w tematyce egzaminowej) – również chętnie zapoznam się z Waszym „co czytam”.

Nie znaleziono powiązanych wpisów.

Powiązane wpisy wygenerowane przez wtyczkę Yet Another Related Posts.

„throw” czy „throw exc” – czyli jak najlepiej przerzucić wyjątek wyżej

andrzej — Thu, 15 Oct 2009 22:31:19 +0000

Pewnie nie raz staliście przed sytuacją, w której jakaś z funkcji spowodować może powstanie wyjątku, którego wystąpienie trzeba zalogować i przerzucić go dalej (re-throw), aby aplikacja zajęła się nim jak należy. Jednocześnie idealnie, gdy wyjątek zawierał będzie jak najwięcej informacji. Zalicza się do nich przyjaciel każdego programisty – StackTrace.

Rozpatrzmy poniższy kod:

public sealed class SomeClass
{
public void SomeTestPublicMethod()
{
try
{
SomeMethod();
}
catch (ApplicationException exc)
{
//logujemy blad
throw exc;
}
}

private void SomeMethod()
{
throw new ApplicationException("Błąd w SomeMethod");

}
}

Czyli testowa klasa, której metodę SomeTestPublicMethod udostępniamy jako publiczną, ona natomiast wywołuje prywatną metodę SomeMethod – rzucającą wyjątek ApplicationException.
Jak widać wystąpienie wyjątku chcemy zalogować w metodzie SomeTestPublicMethod i rzucić wyjątek dalej. Kod wykonujący nasz „błędny” program:

static void Main(string[] args)
{
try
{
SomeClass sc = new SomeClass();
sc.SomeTestPublicMethod();
}
catch (Exception exc)
{
Console.WriteLine(exc.Message);
Console.WriteLine(exc.StackTrace);
}

Console.ReadLine();
}

Czego spodziewacie się w StackTrace? Czy zaprowadzi nas ona do oryginalnej metody SomeMethod, która spowodowała błąd? Otóż niestety nie, StackTrace wygląda tak:

Niepełny StackTrace

Zauważcie, że Message jest w porządku – pochodzi z oryginalnie rzuconego wyjątku. Dokładna informacja o linii wskazuje jednak dopiero na miejsce, w którym napisaliśmy „throw exc;” – czyli SomeTestPublicMethod. Może wydawać się to nieistotne, bez debugowania ciężko byłoby jednak odgadnąć w czym problem i gdzie on tak naprawdę powstaje.
Zamieńmy dosłownie jedną linię – zamiast „throw exc” zróbmy „throw”. Efekt?

Kompletny StackTrace

Różnica? Bogatszy StackTrace wskazujący na oryginalne miejsce powstania błędu – czyli prywatną metodę SomeMethod. Być może zagadnienie niektórym wydaje się trywialne, ale pamiętajcie – jeśli chcecie po prostu „pchnąć” wyjątek dalej, bez utraty informacji (ani opakowania go we własną klasę wyjątku – np. przekazując jako InnerException) używajcie samego „throw”. Oszczędzić może trochę pracy w przyszłości ;)

Powiązane wpisy:

Mutex i sprawdzanie czy aplikacja jest jedyną uruchomioną

Powiązane wpisy wygenerowane przez wtyczkę Yet Another Related Posts.

Własny validator w ASP.NET – CheckBoxListValidator

andrzej — Sat, 19 Sep 2009 22:18:58 +0000

W przedostatnim wpisie, poruszyłem temat napisania własnego walidatora do daty. Dziś napotkałem na podobny problem – walidacja kontrokli CheckBoxList pod kątem zaznaczenia przynajmniej jednej wartości. Jakieś było moje zaskoczenie ;-) gdy okazało się, że żadna z domyślnych kontrolek walidatorów nie potrafi tego niezmiernie skomplikowanego zadania wykonać ;-) Oczywiście można to załatwić banalnie: CustomValidator i odpowiednia prosta funkcja. Gdzie jednak ponowne wykorzystanie kodu – tak przecież przez nas wszystkich lubiane :) W kolejnym projekcie, na kolejnej stronie – nie będziemy przecież kopiować kodu.

W związku z tym, że większość kodu dla walidatorów jest wspólna (różnią się tylko funkcją EvaluateIsValid oraz kodem JS) nie będę zbyt mocno się rozpisywał. Oto kod:

public class CheckBoxListValitator : BaseValidator
{
protected override bool ControlPropertiesValid()
{
return FindControl(ControlToValidate) as CheckBoxList != null;
}

protected override bool EvaluateIsValid()
{
return (FindControl(ControlToValidate) as CheckBoxList).SelectedItem != null;
}

protected override void OnPreRender(EventArgs e)
{
base.OnPreRender(e);

if ((ControlPropertiesValid()) && (this.EnableClientScript))
{
Page.ClientScript.RegisterClientScriptResource(GetType(), "WebControls.Resources.checkboxlist_validate.js");
Page.ClientScript.RegisterExpandoAttribute(ClientID, "evaluationfunction", "validate_CBL");
}
}
}

Wszystko wygląda standardowo:

ControlPropertiesValid – sprawdzamy, czy kontrolka, której ID trzyma property ControlToValidate jest rzeczywiście kontrolką typu CheckBoxList
EvaluateIsValid – sprawdzamy, czy jakikolwiek element został zaznaczony
OnPreRender – podłączamy nasz kod do walidacji po stronie klienta

Kod do walidacji CheckBoxLista po stronie klienta również nie jest zbyt skomplikowany. CheckBoxList jest renderowany jako tabelka, w której komórki są zestawem: input typu checkbox + label z atrybutem for. Wystarczy więc pętlą „przelecieć” po wszystkich elementach tabelki typu checkbox i sprawdzić, czy którykolwiek z nich jest zaznaczony.

CheckBoxList renderowany jako tabelka

Gotowe. Nasz skrypt podłączamy tak jako ostatnio – w zasobach, rejestrując go w pliku AssemblyInfo.cs, w folderze Properties projektu. Jednocześnie oczywiście nie zapominamy o ustawieniu we właściwościah naszego pliku Build Action na Embedded Resource ;)

[assembly: WebResource("WebControls.Resources.checkboxlist_validator.js", "application/x-javascript")]

Demo:
asp.andrzej.net.pl

Kod do pobrania:
Note: There is a file embedded within this post, please visit this post to download the file.

Powiązane wpisy:

Powiązane wpisy wygenerowane przez wtyczkę Yet Another Related Posts.

Własny validator w ASP.NET – Date Validator

andrzej — Wed, 16 Sep 2009 22:25:11 +0000

Kilka dni temu powstał w mej głowie misterny plan opakowania DatePickera od jQuery we własną kontrolkę ASP.NET. Dość łatwo poszło (postaram się to opisać w kolejnym wpisie), jednak chciałem jednocześnie móc walidować wprowadzone dane po stronie klienta i serwera. Niezbędne więc okazało się napisanie własnego Validatora. Nie jest to zadanie zbyt trudne – przedstawię dziś sposób na jego realizację.

Nasza kontrolka – nazwijmy ją DateValidator – nie jest kontrolką wizualną. Nie będzie to więc plik ascx a cs – zwykła klasa. Ja zdecydowałem się na stworzenie oddzielnego assembly – dzięki temu nasz validator wykorzystać będzie łatwo w wielu projektach. Od razu zaznaczę – całośc jest realizowana dla założenia formatu daty dd-MM-yyyy.

Pierwszym krokiem, jaki musimy poczynić, jest wydziedziczenie naszej klasy z klasy BaseValidator (niezbędne jest dodanie do projektu referencji do System.Web).

public class DateValidator : BaseValidator
{
...
}

Następnie zaimplementujmy abstrakcyjną metodę EvaluateIsValid. Można to bardzo sprytnie wykonać z menu kontekstowego wywołanego na klasie bazowej:

Implementacja abstrakcyjnych metod z menu kontekstowego

Porzućmy na chwilę tę metodę – wrócimy do niej.

Z racji tego, że nasza kontrolka do wprowadzania daty będzie dziedziczona z TextBoxa musimy sprawdzić, czy kontrolka, której ID przekaże użytkownik korzystając z property ControlToValidate wskazywać będzie właśnie na kontrolkę tego typu. W tym celu musimy nadpisać metodę klasy bazowej – ControlPropertiesValid. Wystarczy, że odszukamy naszą kontrolkę i sprawdzimy jej typ:

protected override bool ControlPropertiesValid()
{
return (FindControl(ControlToValidate) as TextBox) != null;
}

Wróćmy teraz do implementacji metody EvaluateIsValid. Będzie ona odpowiedzialna za walidację wartości naszego TextBoxa do wprowadzania daty po stronie serwera.

protected override bool EvaluateIsValid()
{
bool ret = false;
TextBox ctrl = FindControl(ControlToValidate) as TextBox;

try
{
DateTime.ParseExact(ctrl.Text, "dd-MM-yyyy", null);
ret = true;
}
catch (FormatException exc)
{
ret = false;
}

return ret;
}

Jedyne co nam pozostało to podłączenie JavaScriptu do walidacji po stronie klienta. Jest to bardzo wygodna forma walidacji – niepotrzebny jest PostBack z cały odsyłaniem zawartości formularza tylko po to, aby sprawdzić, czy użytkownik wprowadził datę poprawnie. Jeden ze sposobów podłączania JS został pokazany we wcześniejszym wpisie. Jednak nie uważam go za wygodny – konserwacja, zmiana czegokolwiek jest dość uciążliwa. Możemy użyć czegoś innego – Resource’ów. Pozwoli to na trzymanie kodu JS w odrębnym pliku – łatwym do ewentualnych poprawek. Utwórzmy więc folder Resources wewnątrz naszego projektu i dodajmy do niego plik date_validate.js. Uwaga – bardzo ważne jest ustawienie we właściwościach dodanego pliku atrybutu Build Action na Embedded Resource. Bez tego nic nie będzie później działać ;-)

Dodanie folderu i pliku zasobów do projektu

Funkcja JS do walidacji musi przyjmować jeden parametr – sender, oraz zwracać wartości true / false.

Dość istotna jest pierwsza linia ciała funkcji. Pobieramy tutaj wartość naszego TextBoxa (a właściwie pola input typu text). Jak widać sender to nasz walidator. Jego property controltovalidate to id kontrolki, którą walidujemy. Wystarczy więc przez polecenie document.getElementById odnaleźć ją i pobrać jej wartość. Samego kodu do walidacji daty nie będę omawiał. Po krótce: do wstępnej walidacji używane są wyrażenia regularne, następnie sprawdzana jest po kolei poprawność daty, tzn. czy ktoś nie wprowadził 31 dnia lutego itp.

Teraz zajmiemy się podłączeniem kodu JS do strony. Najlepiej wykonywać to podczas fazy PreRender. Nie ma zupełnego sensu wcześniej podłączać JS, gdyż np. w fazie Load Visible kontrolki może zostać wyłączona. Wywołanie PreRender zapewnia, że kontrolka będzie widoczna i podłączenie samego kodu ma sens.
Zanim zajmiemy się samym podłączeniem kodu, musimy nasz plik zarejestrować w Assembly jako osadzony zasób. Ogranicza się to do jednego wpisu, którego dokonujemy w pliku AssemblyInfo.cs w katalogu specjalnym Properties naszego projektu:

[assembly: WebResource("WebControls.Resources.date_validate.js", "application/x-javascript")]

Czas na ostatni krok. Nadpisujemy metodę OnPreRender:

protected override void OnPreRender(EventArgs e)
{
base.OnPreRender(e);

if ((ControlPropertiesValid()) && (this.EnableClientScript))
{
Page.ClientScript.RegisterClientScriptResource(GetType(), "WebControls.Resources.date_validate.js");
Page.ClientScript.RegisterExpandoAttribute(ClientID, "evaluationfunction", "CheckDate");
}

}

Zwróćcie uwagę na dwa aspekty – upewniamy się przed podłączeniem, że kontrolka jest odpowiedniego typu (pierwszy warunek) i czy włączona jest walidacja po stronie klienta. Dopiero wtedy korzystając z ClientScriptManagera podłączamy nasz skrypt z zasobów i rejestrujemy naszego delegata evaluationfunction. Gotowe!
Przykład użycia:

<asp:ValidationSummary runat="server" ID="vSummary" />
<asp:TextBox runat="server" ID="Date">asp:TextBox>
<uc:DateValidator runat="server" ID="dvDate" ControlToValidate="Date" Text="*"
ErrorMessage="Wprowadzona data nie jest poprawna">uc:DateValidator>
<asp:Button runat="server" ID="PostBack" Text="Go!" />

Oczywiście wpisywanie daty do takiego prostego pola input jest uciążliwe. Dlatego w jednym z kolejnych wpisów przedstawię sposób na zbudowanie interesującego DatePickera z wykorzystaniem jQuery.

DEMO:
http://asp.andrzej.net.pl/

Plik do pobrania:
Note: There is a file embedded within this post, please visit this post to download the file.

Powiązane wpisy:

Powiązane wpisy wygenerowane przez wtyczkę Yet Another Related Posts.

Show-hide JavaScript – proste podłączenie przy użyciu C#

andrzej — Sun, 16 Aug 2009 17:25:50 +0000

Sponsorem dzisiejszego odcinka są:

JavaScript
Panel
anchor, czyli tag <a href=”">

Cel: podłączanie JS typu „pokaż – ukryj div po kliknięciu w link” jedną linijką kodu w C#

Nie wiem czy to rozwiązanie się Wam spodoba, nie wiem czy jest zgodne z arkanami sztuki JS. Jednak mam to gdzieś ;-) Pracuję nad małym projektem, w którym na stronie znajduje się sporo danych. Są one pogrupowane panelami ASP (czyli po wyrenderowaniu – DIV-ami), którym zapewnić trzeba możliwość ukrywania / pokazywania za pomocą prostego linku (anchor).

Jako, że nie stanowi problemu nadanie atrybutu runat=”server” odpowiedniemu linkowi, postanowiłem zastosować pewien trick celem ułatwienia sobie życia. Prześledźmy to na podstawie „modułu” komentarzy. Do ukrycia mamy całą sekcję, która jest generowana przy użyciu kontrolki repeater.

="server" ID="pComments">
="server" ID="upPanel" UpdateMode="Conditional">

Label runat="server" ID="lblInfo"></asp:Label>
="server" ID="repComments" EnableViewState="false">

......
</ItemTemplate>
</asp:Repeater>
</ContentTemplate>
</asp:UpdatePanel>
</asp:Panel>

Ukrywaniem ma zająć się link:

<h3>Komentarze:

(<a id="aComments" href="#"></a>)</h3>

Oczywiście tekst wyświetlany w innerHTML anchora, powinien zmieniać się w zależności od tego, czy blok jest widoczny czy nie. Wyszperałem prosty skrypt js do ukrywania i pokazywania elementów i zmodyfikowałem go na własne potrzeby. Przetestowałem – działa w przeglądarkach: IE (v. 6,7,8) FF ( v. 1.0 - 3.5) oraz Opera (do v. 10):

Jak widać, funkcja JS powinna dostać ID kontrolki do ukrycia, ID kontrolki ukrywającej oraz dwa teksty: jeden dla schowanego i jeden dla pokazanego DIVa. Teraz pozostaje nam napisać funkcję w C#, która za nas zajmie się podłączaniem JS i renderowaniem go na stronie. Dzięki temu nie trzeba będzie pamiętać o dołączaniu zewnętrznego pliku JS lub – co gorsze – w pisaniu go samemu za każdym razem ;-)

Nasza statyczna funkcja w C# powinna otrzymać:

referencję do strony (w celu podłączenia do niej bloku kodu js)
referencję do kontrolki „do ukrycia” – czyli naszego Panelu
referencję do kontrolki „ukrywającej” – czyli naszego anchora
dwóch tekstów, które pokaże anchor w zależności od stanu
parametru typu bool – decydującego o tym, czy domyślnie dany DIV ma być ukryty czy nie

Dzięki temu, że każda strona w property ClientScript posiada instancję ClientScriptManager’a, możemy bardzo łatwo podłączyć do niej wygenerowany kod js. Kod identyfikowany jest wewnętrznie przez klucz typu string. Pamiętajmy, aby najpierw wykonać sprawdzenie (żeby wielokrotnie nie dołączyć tego samego bloku js do strony):

string key = "ShowHideScript";
public static void AttachShowHideScript(Page page, Panel controlToHide, HtmlAnchor switchControl, string textWhenHide, string textWhenVisible, bool initiallyVisible)
{
if (page.ClientScript.IsClientScriptBlockRegistered(key) == false)
{
//tutaj podłączamy skrypt
}

W celu uniknięcia efektu spaghetti code do renderowania samego kodu JS najlepiej posłyżyć się obiektem klasy HtmlTextWriter.
W naszym przypadku wygenerowanie JS będzie banalne, wystarczy stworzyć instancję klasy StringWriter, następnie instancję wspomnianego HtmlTextWriter, przekazując mu w konstruktorze referencję do StringWritera.

StringWriter sw = new StringWriter();
HtmlTextWriter writer = new HtmlTextWriter(sw);

Sterując ładnie wcięciami, opakowujemy nasz JS przekazując go linia po linii do metody WriteLine:

writer.WriteLine();
writer.Indent = 1;
writer.WriteLine("function jchange(elemToHideId, showHideElemId, textWhenVisible, textWhenHide) {");
writer.Indent = 2;
writer.WriteLine("if (document.getElementById(elemToHideId).style.display == 'none') {");
writer.Indent = 3;
writer.WriteLine("document.getElementById(elemToHideId).style.display = 'block';");
writer.WriteLine("document.getElementById(showHideElemId).innerHTML = textWhenVisible;");
writer.Indent = 2;
writer.WriteLine("} else {");
writer.Indent = 3;
writer.WriteLine("document.getElementById(elemToHideId).style.display = 'none';");
writer.WriteLine("document.getElementById(showHideElemId).innerHTML = textWhenHide;");
writer.Indent = 2;
writer.WriteLine("}");
writer.Indent = 1;
writer.WriteLine("}");

Następnie rejestrujemy kod na stronie, której referencja została nam przekazana:

page.ClientScript.RegisterClientScriptBlock(page.GetType(), key, sw.ToString(), true);

Kolejnym krokiem jest podłączenie do zdarzenia onClick kontrolki anchor, wywołania funkcji javascript. Dostęp do tego zdarzenia w CodeBehind mamy przez property Attributes. Używając String.Format konstruujemy blok wywołania:

switchControl.Attributes["onClick"] = String.Format("jchange('{0}', '{1}', '{2}', '{3}')", controlToHide.ClientID, switchControl.ClientID, textWhenVisible, textWhenHide);

Ostatni krok – ustawiamy tekst wyświetlany przez anchor oraz „widzialność” samego DIVa, zgodnie z wartością przekazaną przez parametr initiallyVisble:

if (initiallyVisible)
{
controlToHide.Style["display"] = "block";
switchControl.InnerHtml = textWhenVisible;
}
else
{
controlToHide.Style["display"] = "none";
switchControl.InnerHtml = textWhenHide;
}

To wszystko. Teraz wystarczy (nie zapominając o nadaniu anchorowi atrybutu runat=”server”) wywołać naszą funkcję, najlepiej na zdarzeniu PreRender strony:

protected void Page_PreRender(object sender, EventArgs e)
{
AttachShowHideScript(Page, pComments, aComments, "pokaż", "ukryj", false);
}

Jeszcze raz kompletny kod funkcji:

public static void AttachShowHideScript(Page page, Panel controlToHide, HtmlAnchor switchControl, string textWhenHide, string textWhenVisible, bool initiallyVisible)
{
string key = "ShowHideScript";

if (page.ClientScript.IsClientScriptBlockRegistered(key) == false)
{
StringWriter sw = new StringWriter();
HtmlTextWriter writer = new HtmlTextWriter(sw);
writer.WriteLine();
writer.Indent = 1;
writer.WriteLine("function jchange(elemToHideId, showHideElemId, textWhenVisible, textWhenHide) {");
writer.Indent = 2;
writer.WriteLine("if (document.getElementById(elemToHideId).style.display == 'none') {");
writer.Indent = 3;
writer.WriteLine("document.getElementById(elemToHideId).style.display = 'block';");
writer.WriteLine("document.getElementById(showHideElemId).innerHTML = textWhenVisible;");
writer.Indent = 2;
writer.WriteLine("} else {");
writer.Indent = 3;
writer.WriteLine("document.getElementById(elemToHideId).style.display = 'none';");
writer.WriteLine("document.getElementById(showHideElemId).innerHTML = textWhenHide;");
writer.Indent = 2;
writer.WriteLine("}");
writer.Indent = 1;
writer.WriteLine("}");

page.ClientScript.RegisterClientScriptBlock(page.GetType(), key, sw.ToString(), true);
}

switchControl.Attributes["onClick"] = String.Format("jchange('{0}', '{1}', '{2}', '{3}')", controlToHide.ClientID, switchControl.ClientID, textWhenVisible, textWhenHide);

if (initiallyVisible)
{
controlToHide.Style["display"] = "block";
switchControl.InnerHtml = textWhenVisible;
}
else
{
controlToHide.Style["display"] = "none";
switchControl.InnerHtml = textWhenHide;
}
}

Oraz kompletny kod HTML.

<h3>
Komentarze:
Label runat="server" ID="lblCommentsCount"> </asp:Label>
<a href="#" runat="server" id="aComments">tutaj będzie tekst "pokaż" / "ukryj"</a>
</h3>
="server" ID="pComments">
Wszystko tutaj będzie ukrywane
</asp:Panel>

Oto efekt w kodzie wygenerowanej strony:

Wygenerowany JS

... oraz automatycznie podpięty pod kontrolki

Powiązane wpisy:

Powiązane wpisy wygenerowane przez wtyczkę Yet Another Related Posts.

Przewodnik po polskich blogach poświęconych C# i .NET

andrzej — Sat, 08 Aug 2009 14:53:04 +0000

Na blogu Macieja Zbrzeznego pojawił się mały przewodnik po polskich blogach poświęconych C# i .NET. Zachęcam do lektury. Kilka blogów wartych jest miejsca w RSS każdego, kto programuje – czy to zawodowo czy dla przyjemności. Chociaż chwilka, czy pierwsza opcja wyklucza drugą ;-) ?

Jak sam autor napisał

lista i opisy mają charakter dość subiektywny, nie mam zamiaru oceniać, czy wskazywać najlepszego. Kolejność została ustalona w sposób nie zamierzony

Taka (krótka) lista aktualnych blogów (czyli takich, na których pojawiały się wpisy w ostatnich miesiącach) jest moim zdaniem bardziej przydatną niż tasiemiec zawierający blogi-zombi.

ps: albo mi się wydaje, albo na blogspocie nie znalazłem opcji trackback…

Nie znaleziono powiązanych wpisów.

Powiązane wpisy wygenerowane przez wtyczkę Yet Another Related Posts.

The Web Application is configured to use IIS. The IIS Web server is not installed on this computer.

andrzej — Fri, 07 Aug 2009 08:27:20 +0000

Nie spotkał Was dotychczas taki komunikat? Ja miałem wątpliwą przyjemność być zaskoczony nim wczoraj ;-)

O co chodzi? Pracując na jednym z komputerów ustawiłem w Properties projektu typu Web Application, aby podczas debugowania nie używała wbudowanego serwera deweloperskiego z VisualStudio, a właśnie lokalnego IIS. Ustawienia były więc jak niżej:

Ustawienia WebApplication

Nieopatrznie wysłałem projekt na SVN z takimi ustawieniami.

„Dzięki” temu nie mogłem później otworzyć projektu na komputerze bez IIS ;-) Powitał mnie komunikat:

Oraz solution, w którym mój projekt został przez przezorne VS wyłączony ;-)

Próba zrobienia reload z menu kontekstowego, kończyła się błędem:

Rozwiązanie jest trywialne, ale może komuś oszczędzi rwania włosów z głowy ;-) Z menu kontekstowego wybieramy „Edit nazwa_projektu.csproj”:

Następnie na końcu pliku, szukamy linii z wpisem:

>True>

i zmieniamy ją na wartość false

Nasze nowe ustawienie

Zapisujemy, ponownie robimy Reload z menu kontekstowego – i gotowe! ;-)

Powiązane wpisy:

Visual Studio – jednoczesne debugowanie kilku projektów w solution

Powiązane wpisy wygenerowane przez wtyczkę Yet Another Related Posts.

ViewState – z czym to się je

andrzej — Wed, 05 Aug 2009 17:18:16 +0000

Postaram się przeprowadzić małą analizę jednego z mechanizmów przechowywania stanów, jakie dostarcza ASP.NET. Mam nadzieję, że poniższy opis ViewState – jego konstrukcji, sposobu przechowywania i zadań jakie spełnia – pozwoli uniknąć kilku problemów podczas programowania. Starałem się wybrać rzeczy najbardziej istotne, zbudować zwarty „przekrój przez ViewState”. Oczywiście wyczerpanie tematu jest niemożliwe, jednak opis ten stanowić może punkt zaczepienia do dalszych rozważań czy poszukiwań.

ASP.NET udostępnia trzy mechanizmy zapamiętywania stanu. Należą do nich:

Application State

Wspólny dla całej aplikacji obiekt typu HttpApplication, dostępny w każdej chwili przez zmienną Application. Stanowi zbiór obiektów definiowanych przez użytkownika, których czas życia jest taki jak czas życia całej aplikacji. Kolekcja Application dostępna jest od czasu wykonania zdarzenia Application_OnStart – czyli wtedy, gdy po uruchomieniu aplikacji na serwerze pierwszy użytkownik wykona do niej żądanie. [1]

Session State

Wspólny dla danej sesji użytkownika. Jest to instancja klasy HttpSessionState, unikalna dla każdej sesji użytkownika i wspólna dla wszystkich jego żądań. Jest to również kolekcja obiektów, niszczona automatycznie po określonym w Web.config czasie braku aktywności użytkownika. Gdu użytkownik inicjuje żądanie po raz pierwszy, serwer tworzy obiekt Session i wysyła do użytkownika jego unikalny identyfikator. Domyślnie identyfikator ten jest zapisywany w cookies, a gdy te nie są dostępne – doklejany do URL każdej strony. Oczywiście można przełączać aplikację między tymi trybami ustawieniami parametru cookieless w web.config. ASP.NET oferuje trzy metody przechowywania sesji, nie to jest jednak przedmiotem wpisu, dlatego polecam doczytać o trybie InProc, StateServer oraz SqlServer.[2]

View State

Czyli nasz dzisiejszy bohater. ViewState to jedna z wyjątkowych cech ASP.NET. To swoista „umiejętność” zapamiętywania stanu kontrolek na konkretnej stronie. Ten „stan widoku” jest generowany przy pierwszym wczytaniu strony aspx i wysyłany do klienta (przeglądarki) w postaci ukrytego pola o nazwie „__VIEWSTATE”. Pole to można znaleźć na każdej stronie stworzonej w ASP.NET (w różnej formie, ale o tym później).

ViewState jest atrybutem typu StateBag klasy System.Web.UI.Control, z której dziedziczą wszystkie kontrolki (w tym strony – czyli instancje klasy System.Web.UI.Page).

Do czego właściwie służy ViewState?

Zastanawiacie się pewnie dlaczego cała ta zabawa z ukrywanym polem, do czego jest to w ogóle potrzebne? Otóż w ASP.NET każde odwołanie do strony powoduje utworzenie jej nowej instancji. Dzieje się tak dlatego, że protokół HTTP jest bezstanowy Siłą rzeczy więc, cykl życia zmiennych zadeklarowanych w kodzie kończy się z chwilą przekazania strony do klienta. Jak w takim razie przechowywać informacje o stanie kontrolek – danych w nich wyświetlanych czy ich właściwościach? Właśnie od tego jest ViewState – zdejmuje z programisty obowiązek zarządzania stanem każdej kontrolki na stronie.

Jakby to było, gdyby go nie było? ;-)

Wyobraźmy sobie sytuację, w której ViewState nie istnieje. Ściągamy z bazy danych informacje, których zażądał użytkownik – np. listę jednostek organizacyjnych – i wyświetlamy ją przy użyciu kontrolki Repeater. Gdyby nie ViewState, przy każdym ponownym odświeżeniu tej samej strony – czyli postbacku – wywołanym przez użytkownika choćby naciśnięciem przycisku, dane musiałyby być ponownie ściągane. Przyznacie, że nie jest to sytuacja komfortowa. ViewState pozwala na zapamiętanie ściągniętych danych i ich odtworzenie przy każdym kolejnym postbacku. Nadmienić należy, iż każda strona posiada property IsPostback, które mówi o tym, czy została ona pokazana po raz pierwszy, czy jest to kolejne odwołanie do niej samej.

Każda kontrolka posiada również property EnableViewState, które pozwala na włączanie lub wyłączanie ViewState’u na niej. Domyślnie ViewState zawsze jest włączony.

W celu zobrazowania przytoczonej powyżej sytuacji (czyli braku ViewState), rozpatrzmy przykład:
umieszczamy na stronie kontrolkę Label z property EnableViewState ustawionym na false oraz Button, który nie wykonuje żadnego konkretnego zadania poza wywołaniem postbacku.

Przy pierwszym załadowaniu strony wpisujemy do kontrolki lblDate aktualną datę – datę pierwszego wyświetlenia tej właśnie strony przez użytkownika:

protected void Page_Load(object sender, EventArgs e)
{
if (!IsPostBack)
{
lblDate.Text = DateTime.Now.ToShortDateString();
}
}

Efekt po pierwszym wywołaniu strony:

Pierwsze odwołanie do strony

Jak widać, wykonał się kod w warunku if(!IsPostback), czyli „gdy jest to pierwsze odwołanie do strony”. Jeśli jednak wywołamy postback strony przyciskiem „Akcja”, efekt będzie taki:

Widok strony po postbacku

Co się stało? Ponowne odwołanie do tej samej strony powoduje, że property IsPostback ma wartość true, więc kod wpisania daty się nie wykonuje. Jednocześnie pozbawiliśmy kontrolkę Label jej wewnętrznej pamięci – poprzednia wartość więc się resetuje i property Text kontrolki jest puste. Gdybyśmy chcieli utrzymać wartość wyświetlaną w kontrolce, najlepszym wyjściem byłoby zachowanie jej wartości w ukrytym polu formularza i odtworzenie przy odwołaniu do strony – czy nie kojarzy się to wam z PHP ;-) ? Właśnie – Microsoft zadbał, by w ASP.NET nie trzeba było martwić się o stan kontrolek i podarował nam ViewState.

Gdybyśmy w powyższym przykładzie zmienili tylko jedną rzecz – property EnableViewState kontrolki Label na wartość true – wielokrotne wywoływanie postbacku przyciskiem „Akcja” nie spowodowałoby zniknięcia/zresetowania raz ustawionej daty. Oczywiście do czasu, gdybyśmy jawnie sami nie zmienili jej wartości. Prawda, że wygodne?

Jak przechowywany jest ViewState?

Jak wspomniałem wczesniej, ViewState domyślnie przechowywany jest na stronie w ukrytym polu. Wysyłany jest więc do przeglądarki z każdym odwołaniem. Jego przykładowy wygląd:

Jak widać nie jest to czysty tekst. Wartość pola kodowana jest alorytmem base64, czyli kodowaniem określanym mianem transportowego. Jest to kodowanie, nie szyfrowanie dlatego należy być ostrożnym w umieszczaniu istotnych, prywatnych danych w kolekcji ViewState. ViewState może być bardzo prosto odkodowany choćby przy użyciu tego dekodera online. Microsoft w oficjalnym artykule prezentuje sposób na parsowanie ViewState’u, na CodeProject natomiast znaleźć możemy artykuł, w którym prezentowana jest realizacja prostej przeglądarki ViewState’u. O zabezpieczeniach, szyfrowaniu ViewState czytaj niżej.

ViewState posiada jeszcze jedną nie do końca dogodną cechę. Tak jak za każdym żądaniem jest wysyłany do klienta, tak przy każdym wywołaniu postbacku musi być odesłany z powrotem na serwer. O ile nie stwarza to problemów przy małych stronach (z niewielką ilością danych) o tyle staje się istotne, gdy ViewState zaczyna ważyć kilka dziesiątek lub setek kilobajtów. Staje się to dodatkowym narzutem do przetransportowania. Na końcu artykułu poruszana jest kwestia wielkości ViewState, prezentowane są także alternatywne metody jego przechowywania.

Jak przechowywać własne obiekty w ViewState

Odpowiedź jest dość prosta – zapewnijmy możliwość serializacji i dodajmy do kolekcji.

Przypuśćmy, że chcemy przechować w ViewState instancję klasy Person:

[Serializable]
public class Person
{
public Person(int id, string name, int age)
{
this._id = id;
this._name = name;
this._age = age;
}

private int _id;

public int Id
{
get { return _id; }
set { _id = value; }
}

private string _name;

public string Name
{
get { return _name; }
set { _name = value; }
}

private int _age;

public int Age
{
get { return _age; }
set { _age = value; }
}
}

O czym trzeba pamiętać?

Kolekcja ViewState przechowuje obiekty – niezbędne jest więc jawne rzutowanie
Przed „wyciągnięciem” obiektu i zrzutowaniem go należy sprawdzić, czy napewno istnieje w kolekcji – czyli czy dla danego klucza typu string wartość jest różna od null (patrz przykład poniżej)
Oznaczenie klasy atrybutem [Serializable]

Wykonanie tych trzech rzeczy gwarantuje wolną od błędów obsługę przechowywania własnych obiektów w ViewState. Poniżej poprawny przykład:

private Person MyPerson
{
get { return ViewState["MyPerson"] == null ? null : (Person)ViewState["MyPerson"]; }
set { ViewState["MyPerson"] = value; }
}

Gdybyśmy jawnie nie wykonali sprawdzenia, czy wartość w kolekcji dla klucza „MyPerson” nie jest równa null i od razu przeprowadzili rzutowanie – jeden z „ulubionych” wyjątków typu NullReference miałby dużą szansę nas zaskoczyć (np. odwołanie przed wpisaniem danych). Z kolei nie oznaczenie klasy jako serializowalnej spowoduje wystąpienie wyjątku HttpException.

Dodatkowo ViewState oferuje kilka metod:

Clear – czyści cały ViewState
Add – dodaje lub (jeśli wpis o takim kluczu istnieje) aktualizuje dane w kolekcji
Remove – pozwala na usunięcie elementu o danym kluczu z kolekcji
IsItemDirty – pozwala na pobranie informacji, czy element o zadanym kluczu został zmieniony podczas przetwarzania ostatniego żądania

Kiedy ViewState jest zapisywany, a kiedy odtwarzany

ViewState zapisywany jest zawsze po zdarzeniu Page_Load (i ewentualnym wykonaniu wszystkich zdarzeń postbacku), przed fazą Render. Oznacza to, że ostatnim miejscem, w którym możemy dokonać zmiany wartości zapisywanych w ViewState jest zdarzenie Page_PreRender. Przed zrenderowaniem strony rekurencyjnie zapisywany jest stan wszystkich kontrolek na stronie, tak aby mógł zostać przesłany jako ukryte pole.

Odtwarzanie ViewState’u występuje tylko przy postbacku, zaraz po inicjalizacji (Page_Init) – dzięki temu w Page_Load mamy już zawsze odtworzony stan strony z ostatniego żądania. Należy pamiętać, że w zdarzeniu Page_Init nie można odczytywać ani wpisywać niczego do ViewState’u – nie jest on jeszcze odtworzony.

Kilka (ważnych) słów o bezpieczeństwie

Na ViewState składają się trzy części (określane jako Triplet):

Hash strony – używa tzw. machine authentication check (MAC). Dołączany dodatkowy hasha na końcu ViewState’u, ograniczający możliwość jego modyfikacji. Jest to dodatkowa suma kontrolna, obliczana z wartości dwóch niżej wymienionych wartości.
Zserializowane stany kontrolek – czyli „rdzeń” ViewState’u, surowe dane
Tablica kontrolek – zawiera listę kontrolek, z których zbudowano ViewState. Strona musi dostarczyć przy postbacku dokładnie tą samą kolekcję kontrolek, w przeciwnym przypadku wystąpi błąd.

Złączenie tych trzech elementów jest kodowane base64 i wysyłane na stronę.

Domyślnie dołączanie MAC jest włączone (przez property EnableViewStateMac). Jak jednak dowiedzieć można się z dokumentacji Microsoftu, czasem może powodować to dziwne zachowanie przy korzystaniu z metody Server.Transfer(). Ustawienie wskazanego property na false rozwiązuje problem, powoduje jednak powstanie dziury bezpieczeństwa – ViewState może zostać odkodowany, zmieniony i odesłany spowrotem do serwera.

Domyślnie do obliczania hasha z użyciem MAC używany jest algorytm SHA1, jednak można zmienić go za pomocą wpisu w web.config.

Przy postbacku następuje odkodowanie ViewState’u i porównanie hasha z właściwymi danymi. Wykrycie modyfikacji spowoduje błąd FormatException lub HttpException.

Szyfrowanie – czy to możliwe?

Tak – możliwe. Jednak należy zadać sobie pytanie, czy skoro myślimy już o szyfrowaniu, to czy na pewno umieszczamy w ViewState dane, które znaleźć się tam powinny? W żadnym razie nie należy w ViewState przechowywać danych, których modyfikacja lub pozyskanie może spowodować niepożądane konsekwencje.

Włączenie szyfrowania polega na odpowiednim ustawieniu wartości elementu machineKey w web.config, w sekcji :

validation="3DES" />

Uwaga – szyfrowana oczywiście nie jest zawartość ViewState a jedynie sam klucz, służący do weryfikacji.

Możliwe jest dołączenie dodatkowego klucza – przy użyciu property strony – ViewStateUserKey. Najlepiej ustawiać wartość (string) tego klucza w zdarzeniu Page_Init. ASP.NET używa go jako parametru wejściowego do algorytmu hashującego, który generuje machine authentication check.

Wielkość ViewState

Nie należy zapominać o tym, że ViewState wprowadza dodatkowy narzut transportowy. Serwer musi wysłać do użytkownika całą stronę i dodatkowo ViewState, natomiast użytkownik odsyła na serwer wartość ukrytego pola przy każdym postbacku. Rozważmy prosty przykład. Na stronie umieścimy kontrolkę Repeater, stworzymy sztuczną listę instancji obiektów typu Person (kod klasy dostępny wyżej). Następnie podłączymy listę jako źródło danych do repeatera i wyświetlimy na stronie.

Kod w pliku aspx:

<asp:Repeater runat="server" ID="repPersons">
<ItemTemplate>
<%# DataBinder.Eval(Container.DataItem, "Id") %>
<%# DataBinder.Eval(Container.DataItem, "Name") %>
<%# DataBinder.Eval(Container.DataItem, "City") %>
<%# DataBinder.Eval(Container.DataItem, "Age") %>
ItemTemplate>
<SeparatorTemplate>
<br />
SeparatorTemplate>
asp:Repeater>

Kod w pliku aspx.cs:

protected void Page_Load( object sender, EventArgs e )
{
if ( !IsPostBack )
{
List<Person> list = new List<Person>();

for ( int i = 0; i < 50; i++ )
{
list.Add( new Person( i + 1, "Name MyName", i + 20 ) );
}

repPersons.DataSource = list;
repPersons.DataBind();
}
}

Jak widać kolekcja liczy 50 osób i przy pierwszym pokazaniu strony podpinana jest do repeatera. Najprostszym sposobem na sprawdzenie wielkości ViewState’u jest wyświetlenie długości ukrytego pola przy użyciu JavaScriptu. To proste zadanie realizuje poniższy kod:

function GetViewStateSize() {
var field = document.forms[0]["__VIEWSTATE"].value;
alert("Rozmiar ViewState (kb): " + field.length / 1024);
}

Który podłączamy do przycisku na stronie:

W moim przypadku wynik wygląda następująco:

Wielkość pola ViewState na stronie

Cała strona waży 5,6kB, ViewState – 2,9kB. Daje to aż 51% wagi całej strony!

Jak pokazuje powyższy bardzo prosty przykład, należy być ostrożnym przy używaniu ViewState’u z kontrolkami, które są pojemnikami na dane, wyświetlają ich znaczną ilość. W literaturze spotyka się zdania, że jeśli waga ViewState’u przekracza 30% wagi całej strony, trzeba pomyśleć o zmianie sposobu przechowywania jego wartości lub inaczej obsłużyć kontrolki, które powodują tak duży jego przyrost. Oczywiście należy podchodzić do tego zagadnienia racjonalnie – jeśli są to takie wielkości jak w przytoczonym przykładzie, nie należy sobie zawracać tym głowy. Jeśli jednak strona waży 200kB-300kB, z czego waga ViewState’u to 50-60% – najwyższy czas pomyśleć o optymalizacji.

Mam nadzieję, że udało mi się przybliżyć temat ViewState’u. Oczywiście poruszone są najważniejsze kwestie, z którymi spotkamy się w codziennym programowaniu. O ViewState można by napisać porządny rozdział w książce, przyznacie jednak, że nie do końca o to chodzi.

Postaram się w kolejnym wpisie poruszyć kwestię przechowywania ViewState’u w postaci innej niż ukryte pole formularza. Możliwości jest kilka – od sesji, przez bazę danych aż po pliki.

Po uporządkowaniu i skomentowaniu kodu źródłowego dołączę go do tego artykułu.

Źródła:

http://www.extremeexperts.com/Net/Articles/ViewState.aspx

http://msdn.microsoft.com/en-us/library/ms972976.aspx#viewstate_topic3

http://www.codeproject.com/KB/viewstate/viewstate_viewer.aspx

http://blog.sb2.fr/post/2008/12/25/Storing-ViewState-On-Server-Instead-Of-Client-With-ASPNET.aspx

http://aspalliance.com/72

http://msdn.microsoft.com/pl-pl/magazine/cc188774(en-us).aspx

Przypisy

http://msdn.microsoft.com/en-us/library/bf9xhdz4(VS.71).aspx
http://msdn.microsoft.com/en-us/library/87069683(VS.71).aspx

Nie znaleziono powiązanych wpisów.

Powiązane wpisy wygenerowane przez wtyczkę Yet Another Related Posts.

Hierarchiczne TreeView z listy obiektów

andrzej — Sat, 25 Jul 2009 19:21:06 +0000

Wielokrotnie stawałem przed problemem zbudowania hierarchicznego TreeView z listy obiektów.
Pisanie odpowiednich foreach, budowanie całej hierarchii TreeNode’ów stało się za którymś razem męczące.

Parę dni temu doczytałem o TreeNodeBindings i postanowiłem chociaż w części zautomatyzować to zadanie. Najpierw przyszło mi na myśl bezpośrednie podpięcie listy do DataSource całego TreeView, jednak jak szybko się okazało kolekcja taka wymaga implementacji interfejsu IHierarchicalEnumerable a jej elementy dodatkowo IHierarchyData.

Bardzo szybko zapadła więc decyzja – nie tędy droga ;-) Chciałem rozwiązania dość uniwersalnego, które nie będzie wymagało dodatkowych działań w klasach.
Jak więc „oszukać” i podłączyć jako DataSource obiekt, który automatycznie odwali za nas częśc pracy? Więc odpowiedź okazała się dość banalna – XML.

Wystarczy zbudować w pamieci obiekt XML, składający się wyłącznie z tych danych, które chcemy pokazywać na drzewie i właśnie jego podłączyć jako DataSource, używając odpowiednio ustawionego TreeNodeBindings.

Pokażę więc poniżej jak to zrealizować.

Na początek prosta klasa, która posłuży do dalszych demonstracji:

public class OrgUnit
{
private int _id;

public int Id
{
get { return _id; }
set { _id = value; }
}

private int _parentId;

public int ParentId
{
get { return _parentId; }
set { _parentId = value; }
}

private string _name;

public string Name
{
get { return _name; }
set { _name = value; }
}

private string _description;

public string Description
{
get { return _description; }
set { _description = value; }
}
}

Jak widać, posiada ona property ParentId – właśnie ono będzie odpowiedzialne za budowanie hierarchii.

Na potrzeby tego przykładu zbudujmy sztuczną listę, którą załadujemy nasze drzewo:

List<OrgUnit> list = new List<OrgUnit>();

list.Add(new XmlTest.OrgUnit(11, -1, "Firma X", ""));
list.Add(new XmlTest.OrgUnit(1, 0, "Dział produkcji", "Dział produkcji zajmuje się..."));
list.Add(new XmlTest.OrgUnit(9, 0, "Dział handlowy", "Dział handlowy zajmuje się..."));
list.Add(new XmlTest.OrgUnit(4, 9, "Dział zamówień", "Dział zamówień zajmuje się..."));
list.Add(new XmlTest.OrgUnit(2, 1, "Dział logistyki", "Dział logistyki zajmuje się..."));
list.Add(new XmlTest.OrgUnit(3, 0, "Dział księgowości", "Dział księgowości zajmuje się..."));
list.Add(new XmlTest.OrgUnit(6, 1, "Dział wysyłki", "Dział wysyłki zajmuje się..."));

list.Sort(
delegate(OrgUnit o1, OrgUnit o2)
{
return o1.ParentId.CompareTo(o2.ParentId);
}
);

Bardzo ważne jest, aby lista była posortowana malejąco według property, któe tworzy hierarchię. Tutaj zrealizowane jest to przy użyciu delegata, ale ładując dane z bazy można po prostu posortować je w procedurze SQL.

Zwróćcie również uwagę, że na początku dodany jest sztuczny element z id równym -1. Ten zabieg jest niestety niezbędny, gdyż dokument XML może zawierać tylko jeden główny element. Najpierw więc dodamy element „Firma X”, który będzie wewnętrz zawierał wszystkie pozostałe. Żaden z pozostałych elementów listy nie wskazuje jako parentId tego głównego (-1). Jest to swoisty sztuczny element, który zdecydowanie ułatwi robotę.

Pierwszym krokiem będzie więc zbudowanie dokumentu XML w pamięci:

XmlDocument xmlDoc = new XmlDocument();
XmlDeclaration xmlDeclaration = xmlDoc.CreateXmlDeclaration("1.0", null, null);
xmlDoc.AppendChild(xmlDeclaration);

Następnie w pętli iterujemy po wszyskich obiektach listy, tworząc odpowiednie elementy xml.

foreach (OrgUnit item in list)
{
XmlElement node = xmlDoc.CreateElement("_" + item.Id);
node.SetAttribute("Id", item.Id.ToString());
node.SetAttribute("ParentId", item.ParentId.ToString());
node.SetAttribute("Name", item.Name);
node.SetAttribute("Description", item.Description);
...
...
}

Teraz najważniejszy element, od którego zależy poprawne wyświetlanie ostatecznych danych.
„Algorytm” dodawania wygląda następująco:

Jeśli element ma Id == -1 dodajemy go jako główny do dokumentu
Jeśli element ma Id == 0 dodajemy go jako drugi w hierarchii element, czyli do elementu z pkt. 1
Jeśli element ma Id > 0 odnajdujemy element, którego Id == ParentId obecnego i wstawiamy do niego

Kod:

if (item.ParentId == -1)
xmlDoc.AppendChild(node);
else if (item.ParentId == 0)
xmlDoc.ChildNodes[1].AppendChild(node);
else
{
string searchExpression = String.Format("//*[@Id=\"{0}\"] ", item.ParentId);
XmlNode parent = xmlDoc.SelectSingleNode(searchExpression);

if (parent != null)
{
parent.AppendChild(node);
}
else
{
throw new Exception("Parent node not found - invalid data");
}

Dość istotne jest odpowiednie użycie xpath do wyszukiwania, w postaci:

String.Format("//*[@Id=\"{0}\"] ", item.ParentId)

Pozwala to na łatwe odszukanie rodzica dla obecnie rozpatrywanego elementu. Oczywiście niezbędne jest sprawdzenie, czy udało się odnaleźć rodzica (!= null). W przeciwnym przypadku ja zdecydowałem się na rzucenie wyjąktu.

Mamy teraz w pamięci dokument XML, zbudujmy więc z niego XmlDataSource, które jest akceptowalne przez TreeView.

W tym celu tworzymy nową instancję klasy XmlDataSource, nadajemy jej unikalne ID i jako property Data wpisujemy nasz stworzony dokument XML:

XmlDataSource dataSource = new XmlDataSource();
dataSource.ID = Guid.NewGuid().ToString();
dataSource.Data = doc.OuterXml;

Teraz wystarczy już tylko poinformować nasze TreeView, których atrybutów XML ma używać do generowania pojedynczego TreeNode’a. W tym celu stworzyć należy obiekt TreeNodeBinding:

TreeNodeBinding binding = new TreeNodeBinding();
binding.TextField = "Name";
binding.ToolTipField = "Description";
binding.ValueField = "Id";

Na samym końcu podpinamy wszystko do naszej instancji TreeView i cieszymy się hierarchiczną strukturą ;-)

treeView1.DataBindings.Add(binding);
treeView.DataSource = dataSource;
treeView.DataBind();

Jeśli po przeczytaniu masz wrażenie, że jest tutaj więcej pracy niż przy zwykłym budowaniu pojedynczych TreeNode’ów i dodawaniu ich ręcznie do kolekcji, to zastanów się, czy przy takim ręcznym generowaniu struktury użyjesz gdzieś drugi raz tego samego kodu?

Rozwązanie, które przedstawiam powyżej śmiało można po niewielkich modyfikacjach dołączyć do prywatnych klas pomocniczych / frameworka i używać go z listami bardzo różnych obiektów. Wystarczy, aby miały one Id oraz ParentId (nawet niekoniecznie tak się nazywające).

Wystarczyłoby stworzyć uniwersalną metodę budującą XML z podanych properties klasy, pobierając ich wartości przy użyciu Reflection. Mam zamiar to zrobić jak tylko znajdę chwilkę – wtedy zamieszczę odpowiedni kod w oddzielnym wpisie.

Tymaczem poniżej możecie pobrać w pełni działające źródło do tego artykułu:
Note: There is a file embedded within this post, please visit this post to download the file.

Powiązane wpisy:

Powiązane wpisy wygenerowane przez wtyczkę Yet Another Related Posts.

„Go to top” po asynchronicznym postbacku w UpdatePanelu

andrzej — Fri, 24 Jul 2009 12:39:29 +0000

Dziś napotkałem banalny wydawać by się mogło problem, ale może komuś oszczędzi grzebania.

Miałem na stronie dwie listy – po lewej długą, po prawej krótką. Wykonanie akcji na lewej liście miało przeładowywać prawą. Realizacja „problemu” oparta o UpdatePanele, ustawione jako conditional. Nie wykonywał się więc postback całej strony a tylko asynchroniczne postbacki wybranych elementów.

Problem polegał na tym, że użytkownik będąc na końcu długiej listy i wywołując akcję nie widział krótkiej listy i nie widział, czy cokolwiek się działo. Najlepszym sposobem byłoby więc JavaScriptowe przewinięcie strony na górę po wykonaniu akcji…

Realizuje to poniższy kod:

function pageLoad() {
var manager = Sys.WebForms.PageRequestManager.getInstance();
manager.add_endRequest(endRequest);
}
function endRequest(sender, args) {
window.scrollTo(0, 0);
}

Jak widać pobierana jest referencja na RequestManager, do której dodajemy „delegata” naszej funkcji JS.
Proste i szybkie ;-) Co ciekawe, w VS2008 Intellisense ujawnia jeszcze kilka ciekawych możliwości:

Intellisense VS2008 - PageRequestManager

Generalnie pierwszy raz miałem do czynienia z UpdatePanelami. Interesująca sprawa dla kogoś, kto (jak ja) ma dwie lewe ręce do JS, jednak, żeby cokolwiek zrobić i mieć pewność, że działa tak jak chcemy… Przygotujcie się na długie lektury internetowych tutoriali. Może skrobnę coś w najbliższym czasie o UpdatePanelu – po tym jak sam się podszkolę ;-)

Nie znaleziono powiązanych wpisów.

Powiązane wpisy wygenerowane przez wtyczkę Yet Another Related Posts.

C# params – tablice parametrów

andrzej — Fri, 10 Apr 2009 19:56:43 +0000

Dotychczas, gdy potrzebowałem metod wykonujących te same zadania ale używających innych parametrów (czy choćby innej liczby parametrów), tworzyłem metody przeciążone. Wydawało mi się to naturalne i logiczne rozwiązanie. Do czasu, gdy przeczytałem o tablicach parametrów właśnie.

Metody, zawierające deklarację parametrów ze słowem kluczowym params, pozwalają na pobranie dowolnej liczby argumentów określonego typu.

Wspomniane przeciążanie jest bardzo przydatne, jednak nie sprawdza się we wszystkich przypadkach, na jakie możemy być „narażeni” ;-) Jednym z owych przypadków jest sytuacja, gdy nie zmienia się typ parametrów a jedynie ich liczba, której nie jesteśmy w stanie przewidzieć.

Książkowym przykładem jest systemowa funkcja WriteLine. Mamy kilka jej odmian:

public static void WriteLine(int parameter)
...
public static void WriteLine(double parameter)
...
public static void WriteLine(decimal parameter)
...

Jak widać, każda pozwala na wypisanie na ekran zmiennej innego typu. Co w sytuacji, gdy mamy do wypisania dwie zmienne typu int? A trzy? Czy tworzyć w tym celu przeciążone metody, przyjmujące odpowiednią ich ilość? Trochę mija się to z celem i jest po prostu … nieładne ;)

W takich sytuacjach z pomocą przychodzą właśnie metody ze zmienną liczbą argumentów – pobierające tablicę parametrów zadeklarowane przy użyciu słowa kluczowego params.

Przykład
Jak to zwykle bywa na blogach, posłużę się przypadkiem nie wziętym z życia, bardzo prostym ale skutecznie (mam nadzieję) obrazującym zagadnienie ;-)

Cel: metoda wyliczająca sumę n-zmiennych typu int.

Wiadomo, że możemy rozwiązać nasz problem przy użyciu metody pobierającej tablicę typu int. Wyglądałoby to następująco:

public class Test
{
public static int Sum ( int[] list )
{
int x = 0;
foreach ( int i in list )
{
x += i;
}
return x;

}
}

Wszystko pozornie wygląda ok. Jaki jest jednak mankament tego rozwiązania? Musimy wcześniej utworzyć tablicę ze zmiennych, które chcemy porównać:

static void Main ( string[] args )
{
int i = 5;
int j = 15;
int k = 23;

int[] array = new int[3];
array[0] = i;
array[1] = j;
array[2] = k;

int sum = Test.Sum( array );
}

Jak widać, wszystko wygląda zgrabnie. Czy aby na pewno? Musimy przecież za każdym razem tworzyć array tylko po to, by zrealizować sumowanie. Czemu nie przerzucić części roboty na kompilator? Zmieńmy więc deklarację metody sumowania na nową:

public static int Sum(params int[] list)
.....

W samym wykonaniu nie zmieniamy niczego. Jak teraz wywołamy metodę sumowania?

static void Main ( string[] args )
{
int i = 5;
int j = 15;
int k = 23;

int sum = Test.Sum( i, j, k );
}

Prawda, że mniej kodu? Tablica i tak zostanie zadeklarowana i zainicjowana naszymi zmiennymi, jednak zrobi to za nas kompilator.

Jak wszystkie rozwiązania, użycie params niesie za sobą kilka dość istotnych ograniczeń. Oto one:

słowa params możemy używać tylko z tablicami jednowymiarowymi
nie możemy przeciążać metody, która używa tylko tablicy z params
nie możemy używać z params słów kluczowych ref i out
jeśli metoda ma inne parametry, ten oznaczony jako params musi być ostatni
w jednej metodzie można użyć tylko jednego artumentu oznaczonego params
metody bez argumentu oznaczonego params mają zawsze wyższy priorytet niż te nim oznaczone

Note: There is a file embedded within this post, please visit this post to download the file.

Nie znaleziono powiązanych wpisów.

Powiązane wpisy wygenerowane przez wtyczkę Yet Another Related Posts.