Kdy správně získat data z datového zdroje a data nabindovat na zobrazovací ovládací prvky, to bylo tématem dnešního rozhovoru a já slíbil, že zkusím obhájit své stanovisko.

Zapředl jsem se totiž do rozhovoru s Martinem a to na základě otázky a jeho odpovědí z tohoto příspěvku. Tazatel se ptal, zda existuje funkce na obnovení dat v GridView a přispěvatel se jménem studentik mu odpověděl, nechť použije událost PreRender. Martin poté upozornil, že tato událost není tím správným místem, kde provést dotaz do datového zdroje a nabindovat data. Odkázal přitom na stránku věnovanou tomuto tématu ASP.NET Page life cycle overview, kde jsou popsány jednotlivé události stránky Page.

Já vycházel z mého již dříve napsaného článku o životním cyklu stránky a zkušeností, které mám s tvorbou asp.net aplikací a nemohl jsem s Martinem souhlasit.

Kdy tedy provést navázání dat?

Nemohu souhlasit s tvrzením, že vázat data na zobrazovací prvky by se mělo již v události Init událostního modelu stránky. V tomto kroku jsou inicializovány jednotlivé prvky a rekonstruuje se objektový model stránky. Samozřejmě, pokud nemáme k dispozici ViewState je to pravé místo, pro to jej "nahradit" a získat tak obraz zobrazovaných dat, tak aby se mohli vytvořit všechny potřebné zobrazovací prvky i s jejich, na klienta, odesílanými údaji.

Posléze, v následujícím zpracování životního cyklu stránky, dojde k načtení dat z ViewState - v případě jeho vypnutí simulujeme napojením dat - a následně k nastavení hodnot formulářových prvků hodnotami z předané kolekce Forms.

Život stránky jde dál a následuje událost Load stránky, kdy se většinou provádí test na vlastnost IsPostBack a případné nahrání a navázání dat. Začátečnickou chybou tak je, že nedojde k otestování zda došlo k postbacku a tak si vývojář přepíše získaná data jejich původní hodnotou a nadělá si spoustu problémů, které neví jak řešit. I proto se mi jeví navázání dat v tomto okamžiku jako nevhodné a vlastně se tím nic nezíská.

A to i vzhledem k tomu, že následuje vyvolání a zpracování změnových např. textchanged a postback událostí - pro prvky implementujících rozhraní IPostBackEventHandler. Kde se snažíme o uložení dat zaslaných klientem do naší aplikace a zároveň můžeme na základě jeho rozhodnutí provádět další operace s naší aplikací. Tyto operace pak mohou vést k tomu, že zdroj dat bude jiný nebo bude obsahovat jiné hodnoty, které v okamžiku zpracování předchozích události ještě nevíme - nebyli jsme o nich informováni, samozřejmě si je můžeme zjistit již dříve, například přímým dotazem na hodnotu do kolekce Forms.

Získání dat a jejich navázání

A právě po proběhnutí výše uvedených akcí je myslím nejvhodnější doba, kdy získat nová data a provést jejich navázání na zobrazovací prvky. Pro verze asp.net 1.x je tedy možné využít události PreRender,pro asp.net 2.0, kde byl událostní model rozšířen, je to událost LoadComplete - samozřejmě je též možné využít PreRender událost.

Určitě se ptáte, jaké k tomu mám podklady, že doporučuji zrovna tyto události. Na prvním místě jsou to osobní zkušenosti, které jen těžko něco může nahradit. Již zmíněné chování, kdy dochází k postupnému "uvědomování si" co vlastně uživatel chce zobrazit až třeba po implementaci asynchronního volání ve verzi asp.net 2.0. Kde je možné si zaregistrovat počáteční a koncový handler v metodě AddOnPreRenderCompleteAsync a kdy ke zpracování asynchronního volání dojde v okamžiku mezi voláním metod OnPreRender a OnPreRenderComplete - tedy taktéž je využito tohoto okamžiku, abychom výsledek zdlouhavé operace navázali na zobrazovací prvek ve stránce.

Samozřejmě budu rád, pokud se mnou nebudete souhlasit a opravíte mě, já se alespoň poučím. Uvítám však i opačný názor, že nejsem sám, kdo k tomuto řešení dospěl.