Autor: admin

Potyczki z Log4net Cz. 2

Na wstępie chciałbym przeprosić, że to tak długo trwało , ale ciężkie życie programisty nie zawsze pozwala mi znaleźć czas na częste blogowanie.
W tej części mojego tutoraiala zajmiemy się samą konfiguracją usługi log4net. Zasadniczo istnieją dwa możliwe podejścia do konfiguracji. Można stworzyć osobny plik konfiguracyjny i nazwać go np. log4net.config lub dodać sekcję do głównego pliku konfiguracyjnego aplikacji. Pierwszym przypadku należy samodzielnie odczytać plik za pomocą api konfiguracyjnego platformy .NET . Np.
using log4net; 
using log4net.Config;
public class MyApp
{
    private static readonly ILog log = LogManager.GetLogger(typeof(MyApp));
    static void Main(string[] args)
    {


        // BasicConfigurator replaced with XmlConfigurator.


        XmlConfigurator.Configure(new System.IO.FileInfo(“log4net.config”));
    }
}
Klasa Xmlconfigurator odczytuje plik configuracyjny i konfiguruje środowisko logowania zgodnie z jego zawartością,
W drugim przypadku aby konfiguracja została odczytana należy zadeklarować sekcję w pliku konfiguracyjnym w sekcji <configsections> następującą dyrektywą :
    <configSections> 
<section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" />
 </configSections>

Całą konfigurację “ubieramy” w znacznik <log4net></log4net>.
Tyle różnic między tymi dwoma metodami. Zawartość konfiuguracji dla obydwu metod jest taka sama. Jakie są mozliwe sekcje ?
  • appender – zero lub więcej elementów . definiuje appendera.
  • logger – zero lub więcej elementów . definiuje konfigurację loggera.
  • renderer – zero lub więcej elementów . Definiuje renderer obiektów.
  • root – opcjonalny element, definiuje konfigurację nadrzędnego loggera.
  • param – zero lub więcej pramaterów definiuje parametry repozytorium.
  • Apendery

    Apendery jak pamiętamy z poprzedniego,artu służą do definiowania targetów na które będą wypluwane wiadomości z naszego loga np. konsola, plik tekstowy. Przykładowa konfiguracja appendera:
    <appender name="ConsoleAppender" type="log4net.Appender.ConsoleAppender" >
    <layout type="log4net.Layout.PatternLayout">
    <conversionPattern value="%date [%thread] %-5level %logger [%ndc] - %message%newline" />
    </layout>
    </appender>


    I tak każdy appender musi mieć nazwę (name). Potrzebne jest do odwołania się do appendera w konfiguracji loggera. Następnie trzeba zdefiniować layout podając typ i format wiadomości. Dokładną listę wszystkich zmiennych można znaleźć w dokumentacji technicznej log4net. Całą magia polega na tym że potem tylko podajemy treść wiadomości,a reszta jest logowana za nas. Oprócz tego tego niektóre appendery wymagają podania dodatkowych paramterów. Definiuje się ję za pomocą elementu <param> .
    Kilka przykładowych appenderów

  • FileAppender – pzowala logować do pliku tekstowego .
  • AdoNetAppender – loguje do bazy danych za pomocą zapytań lub procedur składowych
  • EventLogAppender – zapisuje informacje do dziennika zdarzeń systemu Windows
  • SmtpAppender  – wysyła wiadomości pod wskazany adres e – mail.

    Loggery

    Ogólnie, istnieją dwa rodzaje loggerów w log4net. Logger nadrzędy – root (opcjonalny), oraz loggery zwykłe które dziedziczą od roota. Żeby zdefiniować loggera trzeba określić minimalny poziom logowania oraz opcjonalnie podać odpowiedni appender:

    <logger name="LoggerName"> 
        <level value="DEBUG" />
        <appender-ref ref="ConsoleAppender" />
    </logger>


      Oprócz tego w każdym loggerze można zdefiniować parametr additivity=”true/false” który definiuje czy logger ma dziedziczyć ustawienia z loggerów nadrzędnych.Tak samo jak appender logger może mieć parametry, które definiuje się elementem <param>.

    Renderery      

  • Dla przypomnienia, renderery wywoływane są w momencie gdy jakiś obiekt musi zostać logowany. Rendery są dziećmi elementu log4net i przy deklaracji definiujemy jakiej klasy dotyczy renderer i jak się nazywa klasa która ma go renderować (musi ona implementować interfejs IObjectRenderer ). Przykładowa deklaracja:

    <renderer renderingClass="MyClass.MyRenderer"
    renderedClass="MyClass.MyFunkyObject" />
    Parametry

    Parametry są obecne w całej konfiguracji log4neta i ich użycie sprowadza się
    do zdefiniowania nazwy parametru (name) i jego wartości (value). 
    Warto wspomnieć,że możliwy jest też krótszy zapis . Zamiast:

     <param name="Threshold" value="WARN"/>

    Można napisać :

     <threshold value="WARN"/>

    Na koniec, żeby to wszystko lepiej ogarnąć chciałbym pokazać, 

    jak wygląda gotowa konfiguracja.

    <?xml version="1.0"?> <log4net debug="false">   <root>
        <level value="ALL" />
        <appender-ref ref="FileAppender" />
        <appender-ref ref="ColoredConsoleAppender" />
      </root>
      <logger name="NHibernate" additivity="false">
        <level value="ERROR" />
        <appender-ref ref="FileAppender" />
        <appender-ref ref="ColoredConsoleAppender" />
      </logger>
      <logger name="NHibernate.SQL">
        <level value="ERROR" />
        <appender-ref ref="FileAppender" />
      </logger>
      <!-- Logging - Appenders -->   <appender name="FileAppender" type="log4net.Appender.RollingFileAppender">
        <lockingModel type="log4net.Appender.FileAppender+MinimalLock" />
        <file value="D:LogsLogs.txt" />
        <appendToFile value="true" />
        <maximumFileSize value="10000KB" />
        <maxSizeRollBackups value="100" />
        <layout type="log4net.Layout.PatternLayout">
          <conversionPattern value="%d{ISO8601} %-5p %c{1} - %m%n" />
        </layout>
      </appender>
      <appender name="ColoredConsoleAppender" type="log4net.Appender.ColoredConsoleAppender">
        <mapping>
          <level value="ERROR" />
          <foreColor value="White" />
          <backColor value="Red, HighIntensity" />
        </mapping>
        <mapping>
          <level value="WARN" />
          <foreColor value="White" />
          <backColor value="Yellow" />
        </mapping>
        <mapping>
          <level value="DEBUG" />
          <backColor value="Green" />
        </mapping>
        <layout type="log4net.Layout.PatternLayout">
          <conversionPattern value="%m%n" />
        </layout>
      </appender>
    </log4net>

    Potyczki z Log4net Cz. 1 – Wstęp

    W każdej szanującej się aplikacji powinien być mechanizm logowania. Dobry to taki, który pozwala łatwo kontrolować poziomy logowania i wyrzucać wiadomości do wielu źródeł jednocześnie.
    Biblioteka log4net jest taką biblioteką. Jest łatwa w konfiguracji i obsługuje multum poziomów i targetów. Log4net ma trzy główne compomenty: loggery,appendery i layouty. Najprościej mówiąc appendery zajmują się wyrzucaniem wiadomości do konkretnego miejsca jak np. plik,albo baza. Layouty definiują format wyświetlania wiadomości jak np kolor czcionki na konsoli dla każdego typu wiadomości,albo np. format daty w pliku tekstowym . Loggery kontrolują globalne parametry logowania takie jak poziom logowania. Istnieje 7 poziomów logowania : ALL, DEBUG,INFO,WARN,ERROR,FATAL,OFF . Pierwszy poziom oznacza oczywiście wypluwanie wszystkich typów wiadomości, a ostatni wyłączenie logowania. O poziomie wiadomości decydujemy wywołąc loggera np. :

    logger.Warn("Coś wybuchło");

    Ciekawą właściwością loggerów jest to, że możemy zadeklarować logger nadrzędny. Wtedy wszystkie loggery, które same nie mają zdefiniowane poziomu logowania dziedziczą poziom loggera nadrzędnego i tak dalej aż do roota. Domyślny poziom dla roota to DEBUG.

    Przykład: Loggery root, X i X.Y.Z mają przyporządkowane poziomy odpowiednio: Proot, Px i Pxyz. Logger X.Y dziedziczy swój poziom logowania od swojego rodzica X.

    Logger Poziom Poziom dziedziczony
    root Proot Proot
    X Px Px
    X.Y brak Px
    X.Y.Z brak Px

    Tyle teorii. W następnych częściach zajmiemy się konfiguracją i więcej przykładowego kodu. W kolejnych częściach przyjrzymy się szerzej poszczególnym komponentom.

    The specified solution configuration „Debug|MCD” (oraz Debug|HPD, Debug|BNB itp.) is invalid

    Podczas kompilowania projektu na nowym lapku moim oczom ukazał się komunikat : „The specified solution configuration „Debug|MCD” is invalid” . Po przejrzeniu 10 razy całej konfiguracji i wszystkich opcji konfiguracji nigdzie nie znalazłem wspomnianego MCD. W czym tkwi w konfiguracji komputera a dokładnie samego Windowsa. Należy wejść do edytora rejestru odnaleźć ścieżkę :

    HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSession ManagerEnvironment

    a w niej klucz o nazwie Platfrom . Wystarczy zmienić wartość tego klucza tak aby pozostała pusta. Powoduje to przyjęcie domyślnej platformy przez kompilator .NET Framework.

    Cannot access a disposed object. Object name: ‚DataContext accessed after Dispose

    Czasami podczas wykonywania kodu może się zdarzyć, że nasz kod się wysypie z tym wyjątkiem. Problem ten występuje kiedy próbujemy się odwołać do atrybutów klas LINQ2SQL po usunięciu z pamięci powiązanego z nimi DataContextu, czyli defakto oderwania obiektów od bazy danych. Podstawową przyczyną tego problemu jest niejawna optymalizacja linq2sql zwana lazy loading. Mechanizm ten zakłada że nie ładowane są wszystkie atrybuty i kolejcjie z bazy a jedynie to co jest potrzebne, na podstawie wyrażeń lambda oraz zapytań linq.
    Po pewnym czasie to co jest potrzebne do dalszego przetwarzania zostaje załadowane z pamięci, a DataContext jest niszczony. I właśnie tu pojawia się wspomniany wyjątek . Jest on o tyle ‚zdradliwy’, że może pojawić się znienacka. Typowym scenariuszem, jak udało mi się zauważyć jest przypadek kiedy przekazujemy obiekty linq2sql do Widoku w aplikacji ASP.NET MVC. Bierzemy taki obiekt i odwołujemy kilka stopni głębokości w jego strukturę.Przykładowo mamy sobie obiekt klasy user który zawiera kolekcję wszystkich postów użytkownika, a każdy post zawiera z kolei kolekcję komentarzy. Typowa struktura np. dla Bloga. W tym momecie przy odwołaniu typu User.Posts[0].Coments dostajemy nie za wiele mówiący komentarz ‚Cannot access a disposed object Object name: ‚DataContext accessed after Dispose’. Jest to własnie spowodowane tym co wspomniałem wyżej – linq2sql nie załadował kolekcji komentarzy do pamięci bo zwyczajnie nie wiedział że takowa będzie potrzebna. Czy jest na to jakiś sposób? Oczywiście tzw. best practice mówi żeby nie korzystać z obiektów linq2sql w widokach, no ale co jeśli mamy deadline za pięć dwunasta a musimy poprawić bug w tej aplikacji której programista się rozpędził i nie zawracał sobie głowy jakimiś ViewModelami ? Wtedy jedyną możliwością jest jawne przekazanie do linq żeby ładował kolekcje komentarzy dla każdego Posta. Jak to zrobić ? Przyjrzyjmy się temu fragmentowi kodu:

    var db = new DataContext();
    var dataLoadOptions = new DataLoadOptions();
    dataLoadOptions.LoadWith<Post>(x=>x.Comments);
    db.LoadOptions = dataLoadOptions;

    Tworzymy obiekt klasy DataLoadOptions jest to klasa która definiuje jak się ma zachowywać DataConext podczas ładowania obiektów. Mówimy tu jawnie że jeśli musisz załadować Post to załaduj też jego kolekcję Comments. Taki prosty workaround pozwoli nam cieszyć się działającą aplikacji.

    P.S Chcecie żebym w następnych postach dał kod przykładowych aplikacji ? Dajcie znać w komentarzach.

    Uwaga na wywołania Ajaxowe w firefoxie

    Ostatnio testowałem jeden z projektów pod firefoxem 4. Na jednej ze stron, która miała treści doczytywane ajaxem wszystko się posypało. Firebug przyszedł z pomocą i oznajmił że: „Compoment returen failture Code 0x5435AFFC” (szesnastkowe cyferki przypadkowe) . Zaczynam sie nieco denerwować. Wrzucam stronę pod chrome – działa. IE, Opera, safari – też. Więc o co mu chodzi. Szperając trochę w necie okazało się że firefox przed utworzeniem obiektu XMLHttpRequest waliduje url . Ma to na celu sprawdzić czy nie chcemy wołać ajaxa poza własną domeną. Okazuje się że temu mechanizmowi nie podobają się urle relatywne postaci użytkownicy/lista . Wniosek ? Chcecie żeby wasze aplikacje działały pod firefoxem 4 ? Nie używajcie relatywych adresów url. Albo jeśli akurat zdarza się wam wykorzystywać środowisko ASP.NET, skorzystajcie z Microsoft Ajax Library która sama zamienia nawy metod na poprawne url.

    Telerik radgrid i dropdown filter

    Telerk w swoim pakiecie kontrolek asp.net zabiera bardzo fajną alternatywę dla GridView, która nazywa się RadGrid. Daje na multum opcji dotyczących stylowania, CRUD, oraz sposobu wyświetlania danych. Zawiera też prawie idealną kontrolkę do filtrowania. Nad każdą kolumną w Gridzie dostajemy textboxa oraz komplet pełen komplet fitlrów wprost z SQL . Wręcz idealnie, no prawie 🙂 Często mamy sytuacje że w tablece mamy jakiegoś idka który odwołuję się do pewnej wartośći ze słownika. I co wtedy? dostajemy takiego samego textboxa i zestaw filtrów dla inta. Trochę to mało user friendly chciało by się rzec. Co zrobić z tym fantem ? Tu z pomocą przychodzi nam model obiektowy telerika, który pozwala przeciążyć klasy odpowiedzialne za kolumny i powiedzieć jej żeby używały jakiegos zajebistego dropdowna zamiast tego tandetnego textboxa. Musimy stworzyć klasę dziedziczącą po GridDropDownColumn i przeciążyć w niej następujące metody SetupFilterControls odowiadającą za ustawienie kontrolki filtrującej, SetCurrentFilterValueToControl, która przekazuje bierzącą wartość do kontrolki filtrującej, GetCurrentFilterValueFromControl , która oczywiście wyciąga wartość z kontrolki filtrującej. Przydaje się na koniec obsłużyć zdarzenie SelectedIndexChanged tej kontrolki, żeby filtrowanie wyników następowało po wybraniu jakiejś konkretnej wartości.


    using System;
    using System.Collections.Generic;
    using System.Linq;
    using System.Web;
    using Telerik.Web.UI;
    using System.Web.UI;
    using System.Web.UI.WebControls;
    namespace demo
    {
    public class FilterCombo : GridDropDownColumn
    {
    private object listDataSource = null;
    //RadGrid calls this method when it initializes the controls inside the filtering item cells
    protected override void SetupFilterControls(TableCell cell)
    {
    base.SetupFilterControls(cell);
    cell.Controls.RemoveAt(0);
    DropDownList list = new DropDownList();
    list.ID = "list" + this.DataField;

    list.AutoPostBack = true;
    list.SelectedIndexChanged += new EventHandler(list_SelectedIndexChanged);
    cell.Controls.AddAt(0, list);
    cell.Controls.RemoveAt(1);
    list.DataTextField = this.ListTextField;
    list.DataValueField = this.ListValueField;
    //list.DataSource = this.ListDataSource;
    list.DataSourceID = this.DataSourceID;
    }
    void list_SelectedIndexChanged(object sender, EventArgs e)
    {
    GridFilteringItem filterItem = (sender as DropDownList).NamingContainer as GridFilteringItem;
    if (this.DataType == System.Type.GetType("System.Int32") ||
    this.DataType == System.Type.GetType("System.Int16") ||
    this.DataType == System.Type.GetType("System.Int64"))
    {
    filterItem.FireCommandEvent("Filter", new Pair("EqualTo", this.UniqueName));
    }
    else // treat everything else like a string
    filterItem.FireCommandEvent("Filter", new Pair("Contains", this.UniqueName));
    }
    public object ListDataSource
    {
    get { return this.listDataSource; }
    set { listDataSource = value; }
    }
    //RadGrid calls this method when the value should be set to the filtering input control(s)
    protected override void SetCurrentFilterValueToControl(TableCell cell)
    {
    base.SetCurrentFilterValueToControl(cell);
    DropDownList list = (DropDownList)cell.Controls[0];
    if (this.CurrentFilterValue != string.Empty)
    {
    list.SelectedValue = this.CurrentFilterValue;
    }
    }
    //RadGrid calls this method to extract the filtering value from the filtering input control(s)
    protected override string GetCurrentFilterValueFromControl(TableCell cell)
    {
    DropDownList list = (DropDownList)cell.Controls[0];
    return list.SelectedValue;
    }
    protected override string GetFilterDataField()
    {
    return this.DataField;
    }
    }
    }

    Jak z tego korzystać ? Po pierwsze importujemy naszą klasę do pliku aspx:


    <%@ Register Namespace="demo" Assembly="demo" TagPrefix="demo" %>

    A następnie wywołujemy kolumnę tak jakbyśmy korzystali z GridDropDownColumn.


    <demo:FilterCombo Reorderable="true" DataField="UserId" ReadOnly="true" DataSourceID="UserDataSource"
    DataType="System.String" HeaderText="Nazwa użytkownika" SortExpression="UserId" UniqueName="UserId"
    ListTextField="UserName" ListValueField="UserId">
    </demo:FilterCombo>

    To rozwiązanie ma jedno ale : nie można w prosty sposób wyczyścić filtrów .
    Aby wrócić trzeba dodać dodatkowy przycisk do czyszczenia filtrów w ten sposób :


    <CommandItemTemplate>
    <asp:LinkButton runat="server" ID="LinkButton1" Text="Wyczyć filtrowanie" CommandName="ClearFilters" />
    </CommandItemTemplate>

    i nbsłużyć go w zdarzeniu itemCommand RadGrida:


    protected void RadGrid1_ItemCommand(object source, GridCommandEventArgs e)
    {
    if (e.CommandName == "ClearFilters")
    {
    foreach (GridColumn column in RadGrid1.MasterTableView.Columns)
    {
    column.CurrentFilterFunction = GridKnownFunction.NoFilter;
    column.CurrentFilterValue = String.Empty;
    }
    RadGrid1.MasterTableView.FilterExpression = String.Empty;
    RadGrid1.MasterTableView.Rebind();
    }
    }

    Document.ready() vs pageLoad() – deatchmatch bibliotek Ajax

    Często zdarza się że w projekcie ASN.NET Ajax, oprócz Microsoft Ajax Library używamy jeszcze jQuery . Jest to genialna biblioteka, zachwalana przez wszystkich dot netowych guru jak Scott Gunthrie oraz Omar Al Zahir. Wcześniej czy później napotkamy metody document.ready() oraz pageLoad(). I powstaje pytanie czy można ich używać razem.Otóż TAK! Czy to to samo? Niekoniecznie. Pod maską document.ready() jest zdarzenie DOMContentLoaded, jeśli przeglądarka je obsługuje. Jeśli nie, wywoływane jest zdarzenie window.onLoad. Metoda pageLoad() wykorzystuje uniwersalne odwołanie setTimeout z wartością 0 sekund. Co powoduje że skrypt czeka na załadowanie się całego modelu DOM, przed wywołaniem. Z tym wiąże się 1 pułapka – pageLoad() wywołuje się więcej niż raz – także po każdym postbacku.Na przykład na takiej stronie:


    <script type="text/javascript"> <br /> function pageLoad() { <br /> // to zadziała więcej niż raz <br /> } <br /></script>

    <asp:scriptmanager runat="server">

    <asp:updatepanel runat="server">
    <contenttemplate>
    <asp:button runat="server" id="Button1">
    <asp:literal runat="server" id="TextBox1">
    </asp:literal>
    </asp:button>

    metoda pageLoad() zostanie wywołana po każdym naciśnięciu buttona. Oczywiście w pewnych sytuacjach taka funkcjonalność jest idealna, np.


    <script type="text/javascript">
    function pageLoad() {
    $('#TextBox1').unbind();
    $('#TextBox1').datepicker();
    }
    </script>

    <asp:ScriptManager runat="server" />

    <asp:UpdatePanel runat="server">
    <ContentTemplate>
    <asp:Button runat="server" ID="Button1" />
    <asp:TextBox runat="server" ID="TextBox1" />
    </ContentTemplate>
    </asp:UpdatePanel>

    Wtedy po postbacku plugin datepicker zostanie ponownie powiązany z textboxem. Inaczej utracilibyśmy tą funkcjonalność.
    Podsumowując, pageLoad(), jest metodą wywoływaną wielokrotnie, po załadowaniu strony, oraz przy każdym postbacku. Działa tak samo w każdej przeglądarce. Natomiast document.ready() zawiera optymalizacje dla przeglądarek i jest wywoływana tylko raz po załadowaniu strony. Ciekawostka : Jeśli chcemy osiągnąć funkcjonalność document.ready() (jednokrotne przetwarzanie) bez korzystania z biblioteki jQuery ? Wtedy należy wykożystać metodę S Sys.Application.init. Aby z niej korzystać użyj tego snipletu z kodem:


    <asp:ScriptManager runat="server" />

    <script type="text/javascript">
    Sys.Application.add_init(function() {
    // Kod inicjujący, do uruchomienia tylko raz
    });
    </script>

    Walidacja po stronie serwera z wykorzystaniem kontrolek CustomValidator oraz ValidationCalloutExtender

    Podczas tworzenia reguł walidacji w aplikacji webowej, może się zdarzyć, że standardowe Validatory nie wystarczają, aby zapewnić w pełni funcjonalną walidację. Typowym przykałdem jest sprawdzenie czy czy login już istnieje w bazie. Zwłaszcza, jeśli budujemy aplikację Ajax, która z definicji ma działać bez przeładowania strony. Z pomocą przychodzi. kontrolki CustomValidator oraz validatorCalloutExtender. Aby to osiągnąć wykonujemy następujące czynności.

    Dodajemy rządne Pole tekstowe i validator do strony. Całość otaczamy update panelem:


    <asp:scriptmanager id="ScriptManager1" runat="server">
    <asp:updatepanel id="UpdatePanel1" runat="server">
    <contenttemplate>
    <asp:textbox id="TextBox1" runat="server">

    <asp:button id="Button1" runat="server" text="Button" onclick="Button1_Click">
    <asp:customvalidator id="CustomValidator1" controltovalidate="TextBox1" display="None" runat="server" errormessage="
    This is the text in your Validator Callout Extender error.
    "
    ClientValidationFunction="ValidateTextBox" />
    <cc1:validatorcalloutextender id="ValidatorCalloutExtender1" targetcontrolid="CustomValidator1" runat="server">
    </cc1:validatorcalloutextender>
    </asp:customvalidator>

    Następnie tworzymy skrypt walidacyjny :


    var resultOfTheCallBack;

    function ValidateTextBox(sender, args)
    {
    var textBoxValue = document.getElementById('TextBox1').value;

    // call server callback method passing the value in your textbox
    YourCallBackMethod(textBoxValue);

    if(resultOfTheCallBack == 'Valid')
    args.IsValid = true;
    else
    args.IsValid = false;
    }

    W Evencie Page Load dodajemy kod generujący metodę javascript obsługującą przetwarzanie wa


    string callBackReference = Page.ClientScript.GetCallbackEventReference(this, "arg", "CallBackEventReference", "context");
    string yourCallBackScript = "function YourCallBackMethod(arg, context) { " + callBackReference + "; }";
    Page.ClientScript.RegisterClientScriptBlock(this.GetType(), "YourCallBackMethod", yourCallBackScript, true);

    Na Końcu implementujemy interfejs ICallbackEventHandler


    // ICallbackEventHandler Members
    public string GetCallbackResult()
    {
    return _callBackStatus;
    }

    public void RaiseCallbackEvent(string eventArgument)
    {
    // TUTAJ WSTAW KOD WALIDACYJNY
    if (eventArgument == "junnark")
    _callBackStatus = "Valid";
    }

    To wszystko! .
    Najważniejszą metodą jest GetCallbackResult() która przesyła wynik przetwarzania z powrotem do klienckiej metody zdefiniowanej w Page Load.

    Walidacja po stronie klienta za pomocą ValidatorCalloutExtender

    W Pakiecie AjaxControlToolkit będącego obecnie częścią Microsft AJAX Library znajduje się fajna kontrolka ValidationCalloutExtender. Pozwala ona na wykorzystanie sztandarowych walida torów ASP.NET (RegualExpressionValidator, RequiredFieldValidator itp. ) w scenariuszach Ajaxowych, tzn. do walidacji po stronie klienta. Wszystko jest fajne dopóki walidowany formularz jest wysyłany zwykłym submitem. Problem pojawia się, gdy chcemy zaprogramować przycisk w javascripcie i np. wykorzystać dane do wywołania metody sieciowej. Jak wtedy wywołać nasze Validatory ?Oficjalna dokumentacja milczy na ten temat. Dopiero do głębna analiza kodu javascript dostarczonego z serwera, daje Man bardzo ciekawą metodę:


    function Page_ClientValidate();

    Która zwraca true jeśli formularz został walidowany poprawinie, lub pokazuje „dymki ”:

    I zwraca false jeśli formularz nie został poprawnie walidowany. W tym wypadku nasza funkcja obsługi zdarzenia wyglądała by mniej więcej tak.


    function bt_button1_click(sender,e) {
    if (Page_ClientValidate()) {
    //zrob cos z danymi formularza
    }
    }