Model strony ASP.NET 2.0

autor: Microsoft

W ASP.NET 1.x deweloperzy mieli wybór między wbudowanym modelem kodu a modelem kodu stojącego za kodem. Kod-behind można zaimplementować przy użyciu atrybutu Src lub atrybutu @Page CodeBehind dyrektywy. W ASP.NET 2.0 deweloperzy nadal mają możliwość wyboru między wbudowanym kodem i kodem, ale wprowadzono znaczące ulepszenia modelu opartego na kodzie.

W ASP.NET 1.x deweloperzy mieli wybór między wbudowanym modelem kodu a modelem kodu stojącego za kodem. Kod-behind można zaimplementować przy użyciu atrybutu Src lub atrybutu @Page CodeBehind dyrektywy. W ASP.NET 2.0 deweloperzy nadal mają możliwość wyboru między wbudowanym kodem i kodem, ale wprowadzono znaczące ulepszenia modelu opartego na kodzie.

Ulepszenia modelu Code-Behind

Aby w pełni zrozumieć zmiany w modelu opartym na kodzie w ASP.NET 2.0, najlepiej szybko przejrzeć model, który istniał w ASP.NET 1.x.

Model Code-Behind w wersji ASP.NET 1.x

W ASP.NET 1.x model oparty na kodzie składa się z pliku ASPX (webform) i pliku stojącego za kodem zawierającym kod programowania. Dwa pliki zostały połączone przy użyciu @Page dyrektywy w pliku ASPX. Każda kontrolka na stronie ASPX miała odpowiednią deklarację w pliku za kodem jako zmienną wystąpienia. Plik związany z kodem zawiera również kod powiązania zdarzeń i wygenerowany kod niezbędny dla projektanta programu Visual Studio. Ten model działał dość dobrze, ale ponieważ każdy element ASP.NET na stronie ASPX wymagał odpowiedniego kodu w pliku za pomocą kodu, nie było prawdziwego rozdzielenia kodu i zawartości. Jeśli na przykład projektant dodał nową kontrolkę serwera do pliku ASPX spoza środowiska IDE programu Visual Studio, aplikacja zostanie przerwana z powodu braku deklaracji dla tej kontrolki w pliku za kodem.

Model Code-Behind w wersji ASP.NET 2.0

ASP.NET 2.0 znacznie poprawia ten model. W ASP.NET 2.0 kod jest implementowany przy użyciu nowych klas częściowych dostępnych w ASP.NET 2.0. Klasa za kodem w ASP.NET 2.0 jest zdefiniowana jako klasa częściowa, co oznacza, że zawiera tylko część definicji klasy. Pozostała część definicji klasy jest generowana dynamicznie przez ASP.NET 2.0 przy użyciu strony ASPX w czasie wykonywania lub gdy witryna sieci Web jest wstępnie skompilowana. Link między plikiem za kodem a stroną ASPX jest nadal ustanawiany przy użyciu dyrektywy @ Page. Jednak zamiast atrybutu CodeBehind lub Src ASP.NET 2.0 teraz używa atrybutu CodeFile. Atrybut Dziedziczy służy również do określania nazwy klasy dla strony.

Typowa dyrektywa @ Page może wyglądać następująco:

<%@Page Language="C#" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" %>

Typowa definicja klasy w pliku ASP.NET 2.0 w tle może wyglądać następująco:

public partial class _Default : System.Web.UI.Page

Uwaga

Języki C# i Visual Basic to jedyne języki zarządzane, które obecnie obsługują klasy częściowe. W związku z tym deweloperzy korzystający z języka J# nie będą mogli używać modelu opartego na kodzie w ASP.NET 2.0.

Nowy model rozszerza model związany z kodem, ponieważ deweloperzy będą teraz mieć pliki kodu zawierające tylko utworzony przez nich kod. Zapewnia również prawdziwe rozdzielenie kodu i zawartości, ponieważ nie ma deklaracji zmiennych wystąpień w pliku za kodem.

Uwaga

Ponieważ część klasy dla strony ASPX jest miejscem, w którym odbywa się powiązanie zdarzeń, deweloperzy języka Visual Basic mogą zdać sobie sprawę z niewielkiego wzrostu wydajności, używając słowa kluczowego Handles w kodzie do wiązania zdarzeń. Język C# nie ma równoważnego słowa kluczowego.

Nowe atrybuty dyrektywy @Page

ASP.NET 2.0 dodaje wiele nowych atrybutów do dyrektywy @ Page. Następujące atrybuty są nowe w ASP.NET 2.0.

Async

Atrybut Async umożliwia konfigurowanie strony do wykonania asynchronicznie. Dobrze omówiono strony asynchroniczne w dalszej części tego modułu.

Limit czasu asynchronicznego

Określono limit czasu dla stron asynchronicznych. Wartość domyślna to 45 sekund.

CodeFile

Atrybut CodeFile zastępuje atrybut CodeBehind w programie Visual Studio 2002/2003.

CodeFileBaseClass

Atrybut CodeFileBaseClass jest używany w przypadkach, w których wiele stron ma pochodzić z jednej klasy bazowej. Ze względu na implementację klas częściowych w ASP.NET, bez tego atrybutu klasa bazowa, która używa wspólnych pól do odwołań kontrolek zadeklarowanych na stronie ASPX, nie będzie działać prawidłowo, ponieważ ASP. Aparat kompilacji sieci NETs automatycznie utworzy nowe elementy członkowskie na podstawie kontrolek na stronie. W związku z tym, jeśli chcesz wspólnej klasy bazowej dla co najmniej dwóch stron w ASP.NET, należy zdefiniować klasę bazową w atrybucie CodeFileBaseClass, a następnie uzyskać każdą klasę stron z tej klasy bazowej. Atrybut CodeFile jest również wymagany, gdy ten atrybut jest używany.

Tryb kompilacji

Ten atrybut umożliwia ustawienie właściwości CompilationMode strony ASPX. Właściwość CompilationMode to wyliczenie zawierające wartości Always, Auto i Never. Wartość domyślna to Zawsze. Ustawienie Automatyczne uniemożliwi ASP.NET dynamiczne kompilowanie strony, jeśli jest to możliwe. Wykluczanie stron z kompilacji dynamicznej zwiększa wydajność. Jeśli jednak wykluczona strona zawiera kod, który musi zostać skompilowany, podczas przeglądania strony zostanie zgłoszony błąd.

Włączanie weryfikacji zdarzeń

Ten atrybut określa, czy zdarzenia ogłaszania zwrotnego i wywołania zwrotnego są weryfikowane. Po włączeniu tej opcji argumenty dotyczące ogłaszania zwrotnego lub wywołania zwrotnego są sprawdzane w celu upewnienia się, że pochodzą one z kontrolki serwera, która pierwotnie je renderowała.

Włącz motywy

Ten atrybut określa, czy motywy ASP.NET są używane na stronie. Wartość domyślna to false. ASP.NET motywy zostały omówione w module 10.

LinePragmas

Ten atrybut określa, czy pragmas wiersza należy dodać podczas kompilacji. Pragmas line to opcje używane przez debugery do oznaczania określonych sekcji kodu.

MaintainScrollPositionOnPostback

Ten atrybut określa, czy język JavaScript jest wstrzykiwany do strony, aby zachować położenie przewijania między ogłaszaniem zwrotnym. Ten atrybut jest domyślnie fałszywy .

Jeśli ten atrybut ma wartość true, ASP.NET doda <blok skryptu> podczas ogłaszania zwrotnego, który wygląda następująco:

<script src="/website/WebResource.axd?d=jBAvpwrdOM_V_Xzeox989A2 &t=632653133849531250" type="text/javascript"> </script>

Należy pamiętać, że element src dla tego bloku skryptu to WebResource.axd. Ten zasób nie jest ścieżką fizyczną. Gdy ten skrypt jest żądany, ASP.NET dynamicznie kompiluje skrypt.

Masterpagefile

Ten atrybut określa plik strony wzorcowej dla bieżącej strony. Ścieżka może być względna lub bezwzględna. Strony wzorcowe zostały omówione w module 4.

Motyw arkusza stylów

Ten atrybut umożliwia zastąpienie właściwości wyglądu interfejsu użytkownika zdefiniowanych przez motyw ASP.NET 2.0. Motywy zostały omówione w module 10.

Wartość motywu

Określa motyw strony. Jeśli dla atrybutu StyleSheetTheme nie określono wartości, atrybut Theme zastępuje wszystkie style zastosowane do kontrolek na stronie.

Wartość tytułu

Ustawia tytuł strony. Wartość określona w tym miejscu pojawi się w elemecie <tytułu> renderowanej strony.

Viewstateencryptionmode

Ustawia wartość wyliczenia ViewStateEncryptionMode. Dostępne wartości to Zawsze, Automatycznie i Nigdy. Wartość domyślna to Auto. Gdy ten atrybut jest ustawiony na wartość Auto, stan widoku jest szyfrowany jest żądaniem kontroli przez wywołanie metody RegisterRequiresViewStateEncryption .

Ustawianie wartości właściwości publicznych za pomocą dyrektywy @ Page

Kolejną nową funkcją dyrektywy @ Page w ASP.NET 2.0 jest możliwość ustawienia początkowej wartości właściwości publicznych klasy bazowej. Załóżmy na przykład, że masz właściwość publiczną o nazwie SomeText w klasie bazowej i chcesz zainicjować ją na hello po załadowaniu strony. Można to zrobić, ustawiając wartość w dyrektywie @ Page w następujący sposób:

<%@Page Language="C#" SomeText="Hello!" Inherits="PageBase" %>

Atrybut SomeText dyrektywy @ Page ustawia początkową wartość właściwości SomeText w klasie bazowej na Hello!. Poniższy film wideo to przewodnik ustawiania początkowej wartości właściwości publicznej w klasie bazowej przy użyciu dyrektywy @ Page.

Otwórz Full-Screen wideo

Nowe właściwości publiczne klasy strony

Następujące właściwości publiczne są nowe w ASP.NET 2.0.

AppRelativeTemplateSourceDirectory

Zwraca ścieżkę względną aplikacji do strony lub kontrolki. Na przykład w przypadku strony znajdującej się w http://app/folder/page.aspxlokalizacji właściwość zwraca wartość ~/folder/.

AppRelativeVirtualPath

Zwraca względną ścieżkę katalogu wirtualnego do strony lub kontrolki. Na przykład dla strony znajdującej się w http://app/folder/page.aspxlokalizacji właściwość zwraca wartość ~/folder/page.aspx.

Asynctimeout

Pobiera lub ustawia limit czasu używany do asynchronicznej obsługi stron. (Strony asynchroniczne zostaną omówione w dalszej części tego modułu).

ClientQueryString

Właściwość tylko do odczytu zwracająca część ciągu zapytania żądanego adresu URL. Ta wartość jest zakodowana w adresie URL. Aby zdekodować ją, możesz użyć metody UrlDecode klasy HttpServerUtility.

ClientScript

Ta właściwość zwraca obiekt ClientScriptManager, który może służyć do zarządzania platformą ASP. Emisja NETs skryptu po stronie klienta. (Klasa ClientScriptManager jest omówiona w dalszej części tego modułu).

Enableeventvalidation

Ta właściwość określa, czy walidacja zdarzeń jest włączona dla zdarzeń ogłaszania zwrotnego i wywołania zwrotnego. Po włączeniu argumenty dotyczące ogłaszania zwrotnego lub wywołania zwrotnego są weryfikowane w celu upewnienia się, że pochodzą one z kontrolki serwera, która pierwotnie je renderowała.

Enabletheming

Ta właściwość pobiera lub ustawia wartość logiczną określającą, czy motyw ASP.NET 2.0 ma zastosowanie do strony.

Formularz

Ta właściwość zwraca formularz HTML na stronie ASPX jako obiekt HtmlForm.

Nagłówek

Ta właściwość zwraca odwołanie do obiektu HtmlHead zawierającego nagłówek strony. Możesz użyć zwróconego obiektu HtmlHead, aby pobrać/ustawić arkusze stylów, tagi meta itp.

IdSeparator

Ta właściwość tylko do odczytu pobiera znak używany do oddzielania identyfikatorów kontrolek, gdy ASP.NET tworzy unikatowy identyfikator kontrolek na stronie. Nie jest przeznaczony do użycia bezpośrednio z kodu.

IsAsync

Ta właściwość umożliwia używanie stron asynchronicznych. Strony asynchroniczne zostały omówione w dalszej części tego modułu.

IsCallback

Ta właściwość tylko do odczytu zwraca wartość true , jeśli strona jest wynikiem wywołania zwrotnego. Wywołania zwrotne omówiono w dalszej części tego modułu.

IsCrossPagePostBack

Ta właściwość tylko do odczytu zwraca wartość true , jeśli strona jest częścią ogłaszania zwrotnego między stronami. W dalszej części tego modułu omówiono ogłaszanie zwrotne między stronami.

Elementy

Zwraca odwołanie do wystąpienia IDictionary zawierającego wszystkie obiekty przechowywane w kontekście stron. Możesz dodać elementy do tego obiektu IDictionary i będą one dostępne przez cały okres istnienia kontekstu.

MaintainScrollPositionOnPostBack

Ta właściwość określa, czy ASP.NET emituje język JavaScript, który utrzymuje położenie przewijania stron w przeglądarce po wystąpieniu ogłaszania zwrotnego. (Szczegóły tej właściwości zostały omówione wcześniej w tym module).

Główny

Ta właściwość tylko do odczytu zwraca odwołanie do wystąpienia elementu MasterPage dla strony, do której zastosowano stronę wzorcową.

Masterpagefile

Pobiera lub ustawia nazwę pliku strony wzorcowej dla strony. Tę właściwość można ustawić tylko w metodzie PreInit.

Maxpagestatefieldlength

Ta właściwość pobiera lub ustawia maksymalną długość stanu stron w bajtach. Jeśli właściwość jest ustawiona na liczbę dodatnią, stan widoku stron zostanie podzielony na wiele ukrytych pól, aby nie przekraczać określonej liczby bajtów. Jeśli właściwość jest liczbą ujemną, stan widoku nie zostanie podzielony na fragmenty.

Pageadapter

Zwraca odwołanie do obiektu PageAdapter, który modyfikuje stronę dla przeglądarki żądającej.

Previouspage

Zwraca odwołanie do poprzedniej strony w przypadkach server.Transfer lub odsyłacz zwrotny.

Skinid

Określa ASP.NET 2.0 skóry do zastosowania do strony.

StylSheetTheme

Ta właściwość pobiera lub ustawia arkusz stylów, który jest stosowany do strony.

Templatecontrol

Zwraca odwołanie do kontrolki zawierającej dla strony.

Motyw

Pobiera lub ustawia nazwę motywu ASP.NET 2.0 zastosowanego do strony. Ta wartość musi być ustawiona przed metodą PreInit.

Tytuł

Ta właściwość pobiera lub ustawia tytuł strony w sposób uzyskany z nagłówka stron.

Viewstateencryptionmode

Pobiera lub ustawia viewStateEncryptionMode strony. Zobacz szczegółową dyskusję na temat tej właściwości we wcześniejszej części tego modułu.

Nowe chronione właściwości klasy strony

Poniżej przedstawiono nowe chronione właściwości klasy Page w ASP.NET 2.0.

Adapter

Zwraca odwołanie do kontrolki ControlAdapter, która renderuje stronę na urządzeniu, którego zażądano.

AsyncMode

Ta właściwość wskazuje, czy strona jest przetwarzana asynchronicznie. Jest przeznaczony do użytku przez środowisko uruchomieniowe, a nie bezpośrednio w kodzie.

ClientIDSeparator

Ta właściwość zwraca znak używany jako separator podczas tworzenia unikatowych identyfikatorów klienta dla kontrolek. Jest przeznaczony do użytku przez środowisko uruchomieniowe, a nie bezpośrednio w kodzie.

Pagestatepersister

Ta właściwość zwraca obiekt PageStatePersister dla strony. Ta właściwość jest używana głównie przez deweloperów ASP.NET kontroli.

UniqueFilePathSuffix

Ta właściwość zwraca unikatowy sufiks, który jest dołączany do ścieżki pliku dla przeglądarek buforowania. Wartość domyślna to __ufps= i 6-cyfrowy numer.

Nowe metody publiczne dla klasy strony

Następujące metody publiczne są nowe w klasie Page w ASP.NET 2.0.

AddOnPreRenderCompleteAsync

Ta metoda rejestruje delegatów programu obsługi zdarzeń na potrzeby asynchronicznego wykonywania strony. Strony asynchroniczne zostały omówione w dalszej części tego modułu.

ApplyStyleSheetSkin

Stosuje właściwości w arkuszu stylów stron do strony.

Executeregisteredasynctasks

Ta metoda stanowi asynchroniczne zadanie.

GetValidators

Zwraca kolekcję modułów sprawdzania poprawności dla określonej grupy walidacji lub domyślnej grupy walidacji, jeśli żadna z nich nie jest określona.

RegisterAsyncTask

Ta metoda rejestruje nowe zadanie asynchroniczne. Strony asynchroniczne zostały omówione w dalszej części tego modułu.

Registerrequirescontrolstate

Ta metoda informuje ASP.NET, że stan kontrolki stron musi być utrwalone.

RegisterRequiresViewStateEncryption

Ta metoda informuje ASP.NET, że stan wyświetlania stron wymaga szyfrowania.

ResolveClientUrl

Zwraca względny adres URL, który może być używany dla żądań klientów dla obrazów itp.

SetFocus

Ta metoda ustawi fokus na kontrolkę określoną podczas początkowego ładowania strony.

WyrejestrowywanieRequiresControlState

Ta metoda wyrejestruje kontrolkę przekazywaną do niej, ponieważ nie wymaga już trwałości stanu kontroli.

Zmiany w cyklu życia strony

Cykl życia strony w ASP.NET 2.0 nie zmienił się znacząco, ale istnieją nowe metody, o których należy pamiętać. Cykl życia strony ASP.NET 2.0 został opisany poniżej.

PreInit (nowy w ASP.NET 2.0)

Zdarzenie PreInit jest najwcześniejszym etapem cyklu życia, do którego deweloper może uzyskać dostęp. Dodanie tego zdarzenia umożliwia programową zmianę motywów ASP.NET 2.0, stron wzorcowych, właściwości dostępu dla profilu ASP.NET 2.0 itp. Jeśli jesteś w stanie wycofywania, ważne jest, aby uświadomić sobie, że funkcja Viewstate nie została jeszcze zastosowana do kontrolek w tym momencie w cyklu życia. W związku z tym, jeśli deweloper zmieni właściwość kontrolki na tym etapie, prawdopodobnie zostanie zastąpiony w dalszej części cyklu życia stron.

Init

Zdarzenie Init nie zostało zmienione z ASP.NET 1.x. W tym miejscu chcesz odczytać lub zainicjować właściwości kontrolek na stronie. Na tym etapie strony wzorcowe, motywy itp. są już stosowane do strony.

InitComplete (nowy w wersji 2.0)

Zdarzenie InitComplete jest wywoływane na końcu etapu inicjowania stron. W tym momencie cyklu życia możesz uzyskać dostęp do kontroli dostępu na stronie, ale ich stan nie został jeszcze wypełniony.

Wstępne ładowanie (nowe w wersji 2.0)

To zdarzenie jest wywoływane po zastosowaniu wszystkich danych po powrocie zwrotnym i tuż przed Page_Load.

Ładowanie

Zdarzenie Ładowania nie zostało zmienione z ASP.NET 1.x.

LoadComplete (nowy w wersji 2.0)

Zdarzenie LoadComplete jest ostatnim zdarzeniem na etapie ładowania stron. Na tym etapie wszystkie dane po powrocie zwrotnym i wyświetleniu zostały zastosowane do strony.

Prerender

Jeśli chcesz, aby stan widoku był prawidłowo utrzymywany dla kontrolek dodawanych dynamicznie do strony, zdarzenie PreRender jest ostatnią możliwością dodania ich.

PreRenderComplete (nowy w wersji 2.0)

Na etapie PreRenderComplete wszystkie kontrolki zostały dodane do strony, a strona jest gotowa do renderowania. Zdarzenie PreRenderComplete jest ostatnim zdarzeniem zgłoszonym przed zapisaniem stanu widoku stron.

SaveStateComplete (nowy w wersji 2.0)

Zdarzenie SaveStateComplete jest wywoływane natychmiast po zapisaniu stanu widoku strony i stanu kontroli. Jest to ostatnie zdarzenie, zanim strona zostanie faktycznie renderowana w przeglądarce.

Renderowanie

Metoda Render nie zmieniła się od ASP.NET 1.x. Jest to miejsce, w którym jest inicjowany element HtmlTextWriter, a strona jest renderowana w przeglądarce.

Wycofywanie między stronami w ASP.NET 2.0

W ASP.NET 1.x do opublikowania na tej samej stronie były wymagane postbacks. Powiadomienia zwrotne między stronami nie były dozwolone. ASP.NET 2.0 dodaje możliwość publikowania z powrotem do innej strony za pośrednictwem interfejsu IButtonControl. Każda kontrolka, która implementuje nowy interfejs IButtonControl (Button, LinkButton i ImageButton oprócz kontrolek niestandardowych innych firm) może korzystać z tej nowej funkcji za pomocą atrybutu PostBackUrl. Poniższy kod przedstawia kontrolkę Przycisk, która publikuje z powrotem do drugiej strony.

<asp:Button ID="SubmitReport" PostBackUrl="~/Default.aspx" runat="server" Text="Submit Report" />

Po opublikowaniu strony strona, która inicjuje postback, jest dostępna za pośrednictwem właściwości PreviousPage na drugiej stronie. Ta funkcja jest implementowana za pośrednictwem nowej funkcji WebForm_DoPostBackWithOptions po stronie klienta, która ASP.NET 2.0 jest renderowana na stronie, gdy kontrolka publikuje z powrotem na inną stronę. Ta funkcja JavaScript jest dostarczana przez nową procedurę obsługi WebResource.axd, która emituje skrypt do klienta.

Poniższy klip wideo to przewodnik po zwrotnym po stronie krzyżowej.

Otwórz Full-Screen wideo

Więcej szczegółów na temat poświadczeń zwrotnych między stronami

Viewstate

Być może poproszono Cię już o to, co się stanie z stanem widoku z pierwszej strony w scenariuszu zwrotnym między stronami. W końcu każda kontrolka, która nie implementuje programu IPostBackDataHandler, będzie utrwalać jego stan za pośrednictwem stanu viewstate, więc aby mieć dostęp do właściwości tej kontrolki na drugiej stronie zwrotnej między stronami, musisz mieć dostęp do stanu widoku dla strony. ASP.NET 2.0 zajmuje się tym scenariuszem przy użyciu nowego ukrytego pola na drugiej stronie o nazwie __PREVIOUSPAGE. Pole formularza __PREVIOUSPAGE zawiera stan widoku pierwszej strony, dzięki czemu można uzyskać dostęp do właściwości wszystkich kontrolek na drugiej stronie.

Obejście funkcji FindControl

W przewodniku wideo po powrocie między stronami użyto metody FindControl, aby uzyskać odwołanie do kontrolki TextBox na pierwszej stronie. Ta metoda działa dobrze w tym celu, ale Funkcja FindControl jest kosztowna i wymaga pisania dodatkowego kodu. Na szczęście ASP.NET 2.0 zapewnia alternatywę dla funkcji FindControl w tym celu, która będzie działać w wielu scenariuszach. Dyrektywa PreviousPageType umożliwia silnie typizowane odwołanie do poprzedniej strony przy użyciu atrybutu TypeName lub VirtualPath. Atrybut TypeName umożliwia określenie typu poprzedniej strony, podczas gdy atrybut VirtualPath umożliwia odwoływanie się do poprzedniej strony przy użyciu ścieżki wirtualnej. Po ustawieniu dyrektywy PreviousPageType należy udostępnić kontrolki itp. do którego chcesz zezwolić na dostęp przy użyciu właściwości publicznych.

Laboratorium 1 — publikowanie zwrotne między stronami

W tym laboratorium utworzysz aplikację, która korzysta z nowej funkcji ponarodowej ASP.NET 2.0.

1. Otwórz program Visual Studio 2005 i utwórz nową witrynę sieci Web ASP.NET.

2. Dodaj nowy kształt sieci Web o nazwie page2.aspx.

3. Otwórz plik Default.aspx w widoku projektu i dodaj kontrolkę Przycisk i kontrolkę TextBox.

   1. Nadaj kontrolce Przycisk identyfikator elementu SubmitButton i kontrolkę TextBox identyfikatora userName.
   2. Ustaw właściwość PostBackUrl przycisku na page2.aspx.

4. Otwórz plik page2.aspx w widoku źródłowym.

5. Dodaj dyrektywę @ PreviousPageType, jak pokazano poniżej:

6. Dodaj następujący kod do Page_Load pliku page2.aspx code-behind:

   Response.Write(PreviousPage.UserName.Text);
   

7. Skompiluj projekt, klikając pozycję Kompiluj w menu Kompilacja.

8. Dodaj następujący kod do kodu w pliku Default.aspx:

   public TextBox txtUserName {
       get { return this.UserName; }
   }
   

9. Zmień Page_Load w pliku page2.aspx na następujące:

   Response.Write(PreviousPage.txtUserName.Text);
   

10. Skompiluj projekt.

11. Uruchamianie projektu.

12. Wprowadź swoją nazwę w polu TextBox i kliknij przycisk.

13. Jaki jest wynik?

Asynchroniczne strony w ASP.NET 2.0

Wiele problemów z rywalizacją w ASP.NET wynika z opóźnienia wywołań zewnętrznych (takich jak wywołania usługi internetowej lub bazy danych), opóźnienia operacji we/wy plików itp. Gdy żądanie jest wykonywane względem aplikacji ASP.NET, ASP.NET używa jednego z jego wątków roboczych do obsługi tego żądania. To żądanie jest właścicielem tego wątku do momentu ukończenia żądania i wysłania odpowiedzi. ASP.NET 2.0 stara się rozwiązać problemy z opóźnieniami związane z tymi typami problemów, dodając możliwość wykonywania stron asynchronicznie. Oznacza to, że wątek roboczy może uruchomić żądanie, a następnie przekazać dodatkowe wykonanie do innego wątku, co spowoduje szybkie powrót do dostępnej puli wątków. Gdy plik we/wy, wywołanie bazy danych itp. ukończono, nowy wątek jest uzyskiwany z puli wątków, aby zakończyć żądanie.

Pierwszym krokiem podczas wykonywania strony asynchronicznie jest ustawienie atrybutu asynchronicznego dyrektywy strony w następujący sposób:

<%@ Page Async="true" %>

Ten atrybut informuje ASP.NET o zaimplementowaniu programu IHttpAsyncHandler dla strony.

Następnym krokiem jest wywołanie metody AddOnPreRenderCompleteAsync w punkcie cyklu życia strony przed preRender. (Ta metoda jest zwykle wywoływana w Page_Load). Metoda AddOnPreRenderCompleteAsync przyjmuje dwa parametry; a BeginEventHandler i EndEventHandler. Funkcja BeginEventHandler zwraca element IAsyncResult, który następnie jest przekazywany jako parametr do programu EndEventHandler.

Poniższy film wideo to przewodnik po asynchronicznym żądaniu strony.

Otwórz Full-Screen wideo

Uwaga

Strona asynchronizowana nie jest renderowana w przeglądarce do momentu ukończenia programu EndEventHandler. Bez wątpienia, ale niektórzy deweloperzy będą myśleć o żądaniach asynchronicznych jako podobnych do asynchronicznych wywołań zwrotnych. Ważne jest, aby uświadomić sobie, że nie są. Zaletą żądań asynchronicznych jest to, że pierwszy wątek procesu roboczego może zostać zwrócony do puli wątków w celu obsługi nowych żądań, co zmniejsza rywalizację z powodu ograniczenia operacji we/wy itp.

Wywołania zwrotne skryptów w ASP.NET 2.0

Deweloperzy sieci Web zawsze szukali sposobów zapobiegania migotaniu skojarzonego z wywołaniem zwrotnym. W ASP.NET 1.x usługa SmartNavigation była najczęstszą metodą unikania migotania, ale aplikacja SmartNavigation spowodowała problemy dla niektórych deweloperów ze względu na złożoność implementacji na kliencie. ASP.NET 2.0 rozwiązuje ten problem z wywołaniami zwrotnymi skryptów. Wywołania zwrotne skryptów używają kodu XMLHttp do tworzenia żądań względem serwera internetowego za pośrednictwem języka JavaScript. Żądanie XMLHttp zwraca dane XML, które można następnie manipulować za pośrednictwem modelu DOM przeglądarki. Kod XMLHttp jest ukryty przed użytkownikiem przez nową procedurę obsługi WebResource.axd.

Istnieje kilka kroków niezbędnych do skonfigurowania wywołania zwrotnego skryptu w ASP.NET 2.0.

Krok 1. Implementowanie interfejsu ICallbackEventHandler

Aby ASP.NET rozpoznać stronę jako udział w wywołaniu zwrotnym skryptu, należy zaimplementować interfejs ICallbackEventHandler. Możesz to zrobić w pliku za pomocą kodu w następujący sposób:

public partial class _Default : System.Web.UI.Page, ICallbackEventHandler

Można to również zrobić przy użyciu dyrektywy @ Implements w następujący sposób:

<%@ Implements Interface="System.Web.UI.ICallbackEventHandler" %>

Zazwyczaj używa się dyrektywy @ Implements podczas korzystania z wbudowanego kodu ASP.NET.

Krok 2. Wywołanie metody GetCallbackEventReference

Jak wspomniano wcześniej, wywołanie XMLHttp jest hermetyzowane w procedurze obsługi WebResource.axd. Po renderowaniu strony ASP.NET doda wywołanie do WebForm_DoCallback skryptu klienta udostępnianego przez usługę WebResource.axd. Funkcja WebForm_DoCallback zastępuje funkcję __doPostBack wywołania zwrotnego. Pamiętaj, że __doPostBack programowo przesyła formularz na stronie. W scenariuszu wywołania zwrotnego chcesz zapobiec wycofywaniu, więc __doPostBack nie wystarczy.

Uwaga

__doPostBack jest nadal renderowana na stronie w scenariuszu wywołania zwrotnego skryptu klienta. Nie jest jednak używany do wywołania zwrotnego.

Argumenty funkcji WebForm_DoCallback po stronie klienta są udostępniane za pośrednictwem funkcji Po stronie serwera GetCallbackEventReference, która zwykle jest wywoływana w Page_Load. Typowe wywołanie metody GetCallbackEventReference może wyglądać następująco:

// Set up the JavaScript callback string cbRef = cm.GetCallbackEventReference(this, "document.getElementById('ddlCompany').value", "ShowCompanyName", "null", true);

Uwaga

W takim przypadku cm jest wystąpieniem klasy ClientScriptManager. Klasa ClientScriptManager zostanie omówiona w dalszej części tego modułu.

Istnieje kilka przeciążonych wersji getCallbackEventReference. W takim przypadku argumenty są następujące:

this

Odwołanie do kontrolki, w której jest wywoływana funkcja GetCallbackEventReference. W tym przypadku jest to sama strona.

document.getElementById('ddlCompany').value

Argument ciągu, który zostanie przekazany z kodu po stronie klienta do zdarzenia po stronie serwera. W tym przypadku im przekazuje wartość listy rozwijanej o nazwie ddlCompany.

ShowCompanyName

Nazwa funkcji po stronie klienta, która zaakceptuje wartość zwracaną (jako ciąg) ze zdarzenia wywołania zwrotnego po stronie serwera. Ta funkcja będzie wywoływana tylko wtedy, gdy wywołanie zwrotne po stronie serwera zakończy się pomyślnie. W związku z tym ze względu na niezawodność zaleca się użycie przeciążonej wersji getCallbackEventReference, która przyjmuje dodatkowy argument ciągu określający nazwę funkcji po stronie klienta do wykonania w przypadku błędu.

null

Ciąg reprezentujący funkcję po stronie klienta zainicjowaną przed wywołaniem zwrotnym na serwerze. W takim przypadku nie ma takiego skryptu, więc argument ma wartość null.

true

Wartość logiczna określająca, czy wywołanie zwrotne jest asynchroniczne.

Wywołanie WebForm_DoCallback na kliencie przekaże te argumenty. W związku z tym po renderowaniu tej strony na kliencie kod będzie wyglądać następująco:

WebForm_DoCallback('__Page',document.getElementById('ddlCompany').value, ShowCompanyName,null,null,true)

Zwróć uwagę, że podpis funkcji na kliencie jest nieco inny. Funkcja po stronie klienta przekazuje 5 ciągów i wartość logiczną. Dodatkowy ciąg (który ma wartość null w powyższym przykładzie) zawiera funkcję po stronie klienta, która będzie obsługiwać wszelkie błędy z wywołania zwrotnego po stronie serwera.

Krok 3. Podłącz zdarzenie kontroli Client-Side

Zwróć uwagę, że wartość zwracana powyżej getCallbackEventReference została przypisana do zmiennej ciągu. Ten ciąg służy do zaczepienia zdarzenia po stronie klienta dla kontrolki, która inicjuje wywołanie zwrotne. W tym przykładzie wywołanie zwrotne jest inicjowane przez listę rozwijaną na stronie, więc chcę podłączyć zdarzenie OnChange .

Aby podłączyć zdarzenie po stronie klienta, po prostu dodaj procedurę obsługi do znaczników po stronie klienta w następujący sposób:

// Hook the JavaScript function to the onchange event of the dropdown ddlCompany.Attributes["onchange"] = String.Format("javascript:{0}", cbRef);

Przypomnij sobie, że cbRef jest wartością zwracaną z wywołania polecenia GetCallbackEventReference. Zawiera wywołanie WebForm_DoCallback pokazane powyżej.

Krok 4. Rejestrowanie skryptu Client-Side

Pamiętaj, że wywołanie polecenia GetCallbackEventReference określono, że skrypt po stronie klienta o nazwie ShowCompanyName zostanie wykonany, gdy wywołanie zwrotne po stronie serwera zakończy się powodzeniem. Ten skrypt należy dodać do strony przy użyciu wystąpienia ClientScriptManager. (Klasa ClientScriptManager zostanie omówiona w dalszej części tego modułu). Robisz to w następujący sposób:

System.Text.StringBuilder clientScript = new System.Text.StringBuilder(""); ClientScriptManager cm = Page.ClientScript; // Create the client script clientScript.Append("function ShowCompanyName(companyName)"); clientScript.Append("{"); clientScript.Append("document.getElementById('CoClicked').innerHTML = \"You chose \" + companyName + \".\";"); clientScript.Append("}"); cm.RegisterClientScriptBlock(this.GetType(), "showCo", clientScript.ToString(), true);

Krok 5. Wywoływanie metod interfejsu ICallbackEventHandler

Program ICallbackEventHandler zawiera dwie metody, które należy zaimplementować w kodzie. Są to RaiseCallbackEvent i GetCallbackEvent.

RaiseCallbackEvent przyjmuje ciąg jako argument i nie zwraca nic. Argument ciągu jest przekazywany z wywołania po stronie klienta do WebForm_DoCallback. W takim przypadku ta wartość jest atrybutem wartości listy rozwijanej o nazwie ddlCompany. Kod po stronie serwera powinien zostać umieszczony w metodzie RaiseCallbackEvent. Jeśli na przykład wywołanie zwrotne wykonuje element WebRequest względem zasobu zewnętrznego, ten kod powinien zostać umieszczony w elemecie RaiseCallbackEvent.

GetCallbackEvent jest odpowiedzialny za przetwarzanie zwrotu wywołania zwrotnego do klienta. Nie przyjmuje żadnych argumentów i zwraca ciąg. Zwracany ciąg zostanie przekazany jako argument funkcji po stronie klienta, w tym przypadku ShowCompanyName.

Po wykonaniu powyższych kroków możesz wykonać wywołanie zwrotne skryptu w ASP.NET 2.0.

Otwórz Full-Screen wideo

Wywołania zwrotne skryptów w ASP.NET są obsługiwane w dowolnej przeglądarce obsługującej wykonywanie wywołań XMLHttp. Obejmuje to wszystkie nowoczesne przeglądarki używane obecnie. Program Internet Explorer używa obiektu XMLHttp ActiveX, podczas gdy inne nowoczesne przeglądarki (w tym nadchodzące IE 7) używają wewnętrznego obiektu XMLHttp. Aby programowo określić, czy przeglądarka obsługuje wywołania zwrotne, można użyć właściwości Request.Browser.SupportCallback . Ta właściwość zwróci wartość true , jeśli żądający klient obsługuje wywołania zwrotne skryptów.

Praca ze skryptem klienta w ASP.NET 2.0

Skrypty klienta w ASP.NET 2.0 są zarządzane przy użyciu klasy ClientScriptManager. Klasa ClientScriptManager śledzi skrypty klienta przy użyciu typu i nazwy. Zapobiega to programowemu wstawieniu tego samego skryptu na stronie więcej niż raz.

Uwaga

Po pomyślnym zarejestrowaniu skryptu na stronie każda kolejna próba zarejestrowania tego samego skryptu spowoduje, że skrypt nie zostanie zarejestrowany po raz drugi. Nie dodano zduplikowanych skryptów i nie wystąpi wyjątek. Aby uniknąć niepotrzebnych obliczeń, istnieją metody, których można użyć do określenia, czy skrypt jest już zarejestrowany, aby nie próbować go zarejestrować więcej niż raz.

Metody clientScriptManager powinny być znane wszystkim bieżącym deweloperom ASP.NET:

Registerclientscriptblock

Ta metoda dodaje skrypt w górnej części renderowanej strony. Jest to przydatne w przypadku dodawania funkcji, które będą jawnie wywoływane na kliencie.

Istnieją dwie przeciążone wersje tej metody. Wśród nich są wspólne trzy z czterech argumentów. Są to:

type (string)

Argument typu identyfikuje typ skryptu. Zazwyczaj dobrym pomysłem jest użycie typu strony (to. GetType()) dla typu.

key (string)

Klucz argument jest kluczem zdefiniowanym przez użytkownika dla skryptu. Powinno to być unikatowe dla każdego skryptu. Jeśli spróbujesz dodać skrypt z tym samym kluczem i typem już dodanego skryptu, nie zostanie on dodany.

script (string)

Argument skryptu to ciąg zawierający rzeczywisty skrypt do dodania. Zaleca się użycie klasy StringBuilder do utworzenia skryptu, a następnie użycie metody ToString() w programie StringBuilder w celu przypisania argumentu skryptu .

Jeśli używasz przeciążonego elementu RegisterClientScriptBlock, który przyjmuje tylko trzy argumenty, musisz uwzględnić elementy skryptu (<skrypt> i </script) w skrypcie>.

Możesz użyć przeciążenia elementu RegisterClientScriptBlock, które przyjmuje czwarty argument. Czwarty argument jest wartością logiczną określającą, czy ASP.NET należy dodać elementy skryptu. Jeśli ten argument ma wartość true, skrypt nie powinien jawnie uwzględniać elementów skryptu.

Użyj metody IsClientScriptBlockRegistered, aby określić, czy skrypt został już zarejestrowany. Pozwala to uniknąć próby ponownego zarejestrowania skryptu, który został już zarejestrowany.

RegisterClientScriptInclude (nowy w wersji 2.0)

Tag RegisterClientScriptInclude tworzy blok skryptu, który łączy się z zewnętrznym plikiem skryptu. Ma dwa przeciążenia. Jeden przyjmuje klucz i adres URL. Drugi dodaje trzeci argument określający typ.

Na przykład poniższy kod generuje blok skryptu, który łączy się z jsfunctions.js w katalogu głównym folderu scripts aplikacji:

ClientScriptManager cm = Page.ClientScript; if(!cm.IsClientScriptIncludeRegistered("jsfunc")) { cm.RegisterClientScriptInclude(this.GetType(), "jsfunc", "/scripts/jsfunctions.js"); }

Ten kod tworzy następujący kod na renderowanej stronie:

<script src="/scripts/jsfunctions.js" type="text/javascript"></script>

Uwaga

Blok skryptu jest renderowany w dolnej części strony.

Użyj metody IsClientScriptIncludeRegistered, aby określić, czy skrypt został już zarejestrowany. Pozwala to uniknąć próby ponownego zarejestrowania skryptu.

Registerstartupscript

Metoda RegisterStartupScript przyjmuje te same argumenty co metoda RegisterClientScriptBlock. Skrypt zarejestrowany w języku RegisterStartupScript jest wykonywany po załadowaniu strony, ale przed zdarzeniem po stronie klienta OnLoad. W wersji 1.X skrypty zarejestrowane w kodzie RegisterStartupScript zostały umieszczone tuż przed zamykającym </formularzem> tagu, podczas gdy skrypty zarejestrowane w elemecie RegisterClientScriptBlock zostały umieszczone bezpośrednio po tagu formularza> otwierającego<. W ASP.NET 2.0 oba są umieszczane bezpośrednio przed zamykającym </formą> tagu.

Uwaga

Jeśli zarejestrujesz funkcję za pomocą języka RegisterStartupScript, ta funkcja nie zostanie wykonana, dopóki nie zostanie jawnie wywołana w kodzie po stronie klienta.

Użyj metody IsStartupScriptRegistered, aby określić, czy skrypt został już zarejestrowany i uniknąć próby ponownego zarejestrowania skryptu.

Inne metody ClientScriptManager

Oto niektóre z innych przydatnych metod klasy ClientScriptManager.

Getcallbackeventreference	Zobacz wywołania zwrotne skryptów we wcześniejszej wersji tego modułu.
GetPostBackClientHyperlink	Pobiera odwołanie w języku JavaScript (javascript:<call>), którego można użyć do powrotu z zdarzenia po stronie klienta.
Getpostbackeventreference	Pobiera ciąg, którego można użyć do zainicjowania wpisu z powrotem od klienta.
Getwebresourceurl	Zwraca adres URL do zasobu osadzonego w zestawie. Musi być używany w połączeniu z RegisterClientScriptResource.
Registerclientscriptresource	Rejestruje zasób internetowy na stronie. Są to zasoby osadzone w zestawie i obsługiwane przez nową procedurę obsługi WebResource.axd.
Registerhiddenfield	Rejestruje ukryte pole formularza na stronie.
Registeronsubmitstatement	Rejestruje kod po stronie klienta, który jest wykonywany po przesłaniu formularza HTML.