URL Routing – tahák pro každého

Dneska se chci věnovat nové vlastnosti .NET Frameworku 4 pro Web Formové aplikace a to URL Routingu. Co to vlastně je? URL routing je technika, díky které má uživatel k dispozici takzvané hezké url adresy stránek (např. http://www.mujweb.cz/product/156) a vývojář spoustu starostí. Nicméně je nutno říci, že díky URL Routingu to již není takový problém ve srovnání se psaním vlastního http modulu. Tak tedy směle do toho.

Vlastní URL routing by se dal rozdělit do tří částí, respektive do tří ohraničených problémů. Jsou to: Mapování stránek, čtení parametrů na těchto stránkách a vytváření odkazů na spravované stránky. Postupně se na všechny tyto případy podíváme.

Mapování stránek

Pod tímto si můžeme představit vytváření routovací tabulky, díky které se překládají hezké url adresy na interní url adresy. Tedy již zmiňovaná adresa http://www.mujweb.cz/product/156 by jako interní adresa vypadala takto http://www.mujweb.cz/product.aspx?IDproduct=156. Tyto pravidla patří do souboru Global.asax a to do metody Application_Start.

void Application_Start(object sender, EventArgs e) 
{
   RouteTable.Routes.MapPageRoute(
	"Home", 
	"home", 
	"~/Default.aspx");
   RouteTable.Routes.MapPageRoute(
	"About", 
	"about", 
	"~/About.aspx");
   RouteTable.Routes.MapPageRoute(
	"Product", 
	"product/{IDproduct}", 
	"~/Product.aspx");
   RouteTable.Routes.MapPageRoute(
	"Detail", 
	"detail/{IDproduct}/{IDtype}", 
	"~/Detail.aspx");
   RouteTable.Routes.MapPageRoute(
	"GuestBook", 
	"guestbook/{IDuser}/{Date}", 
	"~/GuestBook.aspx", 
	true, 
	new RouteValueDictionary { {"Date", DateTime.Now}});
   RouteTable.Routes.MapPageRoute(
	"GuestBookRestrict", 
	"guestbookrestrict/{IDuser}/{Date}", 
	"~/GuestBook.aspx", 
	true, 
	new RouteValueDictionary { { "Date", DateTime.Now } }, 
	new RouteValueDictionary { { "IDuser", @"\d+" }, { "Date", @".+" } });
   //Zakážeme rotování systémových zdrojů
  RouteTable.Routes.Ignore(
	"{resource}.axd/{*pathInfo}");
}

Tato routovací tabulka vypadá poněkud nepřehledně, ale pokud se na tyto pravidla podíváme z blízka, zjistíme, že to nebude tak hrozné. První pravidlo, které se jmenuje “Home”, říká že pokud je url adresa http://www.mujweb.cz/home tak přesměruj na stránku http://www.mujweb.cz/Default.aspx. Což je jednoduché a přehledné. Druhé pravidlo “About” se chová podobně, ale zato třetí pravidlo “Product” je již zajímavější. Ve třetím pravidle se již pracuje s parametry a to takto: pokud je url adresa http://www.mujweb.cz/produkt/111 tak přesměruj na stránku http://www.mujweb.cz/Product.aspx?IDproduct=111. Stejné problematice se věnuje i čtvrté pravidlo “Detail” s tím rozdílem, že dokáže obsloužit více parametrů. Zase o něco zajímavější je páté pravidlo “GuestBook”, ve kterém se parametru Date nastavuje výchozí hodnota a to aktuální datum. Takže pokud je parametr uveden v adrese je použit, jinak se použije výchozí hodnota. A  nejzajímavější je pravidlo předposlední “GuestBookRestrict”, které ke všem předchozím funkcí ještě umožňuje testovat hodnotu parametru za pomoci regulárního výrazu. Pokud parametr nesplňuje pravidla, toto přesměrování se neprovede a skončíme na hlášení, že stránka neexistuje. Poslední pravidlo na rozdíl od předchozích umožňuje ignorovat definovanou adresu. v příkladu je vidět, ignorace všeho co končí příponou axd a za touto příponou může být cokoliv, což symbolizuje ona hvězdička. Závěrem tohoto bloku bych snad jen upozornil na to, že pravidla se nastavují metodou MapPageRoute nikoliv Add ačkoliv to k tomu svádí!

Čtení parametrů

Druhým problémkem je ve stránce, na kterou jsme uživatele pomocí interní url přesměrovali, přečíst parametry. Zase se zde dá říci, že to není nic složitého. Způsoby jak to udělat jsou dva, a to v obslužném kódu stránky, nebo přímo ve stránce deklarativně. V obslužném kódu stránky máme od verze Frameworku 4 k dispozici nový objekt RouteData, což je objekt umístěný v namespacu System.Web.Routing a je také vlastností objektu Page. Použití si ukážeme na příkladu kdy parametr IDproduct uložíme do proměnné MyIDproduct.

int MyProdukt = (int)RouteData.Values["IDproduct"];

Přičemž vlastnost Values obsahuje kolekci url parametrů. Druhým způsobem výpisu parametrů je již zmiňovaný deklarativní zápis.

<%$ RouteValue:IDproduct %>

Vytváření odkazů

A jsme u posledního úkolu a to je vytvořit nějak inteligentně odkazy ve stránkách tak, aby se odkazovaly na naše hezká url. Jistě by někoho mohlo napadnout si tyto odkazy prostě sestrojit řekněme běžným způsobem, ale toto asi není úplně to, co bychom si přestavili pod termínem inteligentní řešení. Super by bylo říct jaký odkaz chceme vytvořit, respektive dle jakého routovacího pravidla chceme vytvořit odkaz obsahující hezké url a případně dodat nějaké ty parametry. A přesně takto to funguje. Jednoduchý odkaz bez parametrů vypadá následovně:

 string MyNiceURL = GetRouteUrl("Home", null);

Výsledkem našeho snažení bude url adresa http://www.mujweb.cz/home. Pokud zatoužíme mít v url adrese i nějaké ty parametry, tak máme k dispozici několik způsobů jak to udělat. Jedním způsobem je nahrazení parametru null z předchozího příkladu za ony parametry:

 string MyNiceURL = GetRouteUrl(
                       "Home",     
                       new { IDproduct=200 });

případně více parametrů:

 string MyNiceURL = GetRouteUrl(
              "Home",     
              new { IDproduct=200, IDtype = 1 });

Nebo to jde i o maličko složitěji:

RouteValueDictionary DalsiParametry = 
new RouteValueDictionary 
        { 
	  { "IDproduct", "400" }, 
          { "IDtype", "2" } 
        };
VirtualPathData DalsiVirtualniAdresa = RouteTable.Routes.GetVirtualPath(
                                 null, 
	                         "Detail", 
                                 DalsiParametry);
string MyNiceURL = DalsiVirtualniAdresa.VirtualPath;

Závěr

A to je vše co potřebujeme vědět k tomu, abychom mohli úspěšně routovat url adresy. Pokud by tento tahák nestačil, více informací o tomto tématu naleznete jako vždy na MSDN.

Ještě dodám jednu informaci na kterou jsem již stačil přijít v praxi. Při změně NET Frameworku z 3.5 na 4 a následném pokusu o URL Routing to jaksi nefungovalo. Vše začalo fungovat až s tímto nastavením webserveru:

<system.webserver>
 <modules runallmanagedmodulesforallrequests="true" />
</system.webserver>

Příklad jednoduchého webu s routováním url adres je ke stažení zde.

Oblíbené regulární výrazy

Regulární výrazy jako takové jsou obrovskou kapitolou sami osobě, a v žádném případě se nechci pouště do toho, abych je zde podrobně rozebíral. Nicméně rád bych zde zmínil několik opakujících se výrazů.

Testování schody pomocí regulárních výrazů

Myslím, že nejpoužívanější výraz je ověření e-mailu:

[a-zA-Z0-9._-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,5}

Běžně je k vidění omezení délky domény nejvyššího řádu od 2 do 4 znaků. Já osobně preferuji nastavení od 2 do 5 znaků, z důvodu testování domény .local vhodnou například v intranetech.

Další frekventovaný případ regulárního výrazu je ověření telefonního čísla:

^(\+420)? ?[0-9]{3} ?[0-9]{3} ?[0-9]{3}$

Následuje regulární výraz pro ověření poštovního směrovací čísla:

\d{3} ?\d{2}

Následující výraz je poměrně obsáhlý, nicméně jeho rozsah je famózní. Dokáže otestovat URL adresu protokolu http, https, ftp a povoluje jak doménové jména tak i IP adresu ve verzi 4:

(http|https|ftp)\://([a-zA-Z0-9\.\-]+(\:[a-zA-Z0-9\.&%\$\-]+)*@)?((25[0-5]|2[0-4][0-9]|[0-1]{1}[0-9]{2}|[1-9]{1}[0-9]{1}|[1-9])\.(25[0-5]|2[0-4][0-9]|[0-1]{1}[0-9]{2}|[1-9]{1}[0-9]{1}|[1-9]|0)\.(25[0-5]|2[0-4][0-9]|[0-1]{1}[0-9]{2}|[1-9]{1}[0-9]{1}|[1-9]|0)\.(25[0-5]|2[0-4][0-9]|[0-1]{1}[0-9]{2}|[1-9]{1}[0-9]{1}|[0-9])|([a-zA-Z0-9\-]+\.)*[a-zA-Z0-9\-]+\.[a-zA-Z]{2,4})(\:[0-9]+)?(/[^/][a-zA-Z0-9\.\,\?\'\\/\+&%\$#\=~_\-@]*)* 

Náhrady pomocí regulárních výrazů

Velmi oblíbený regulární výraz, který má využití například v diskusních fórech je náhrada URL adresy za odkaz na adresu:

Regulární výraz:

((http://)|(www\.))([^ ]+[^,. ])

Náhrada:

<a href="http://$3$4">$2$3$4</a>

Občas se hodí výraz pro náhradu určitého tagu v html dokumentu za jiný. V tomto nám může dobře posloužit následující regulární výraz ve kterém nahradíme tag za hledaný html tag a novytag za cílový html tag.

Regulární výraz:

<(/?)tag([^>]*)>

Náhrada:

<$1novytag$2>

a pokud bychom chtěli krom html tagu nahradit i atributy je možné to udělat tímto regulárním výrazem kde tag nahradíme hledaným html tagem a atribut atributem jako například class=”priklad”. No a jak jste si již domysleli, tak novytag nahradíme cílovým html tagem.

Regulární výraz:

<(tag)\s+(atribut)>([^<]+)</\1>

Náhrada:

<novytag $2>$3</novytag>

Poslední ukázkou bude nahrazení textu mezi konkrétními tagy. Zde můžeme v náhradě použít buďto pouze nový text nebo alias $1, který se zamění za původní text a tak vlastně nový text rozšířit o ten původní.

Regulární výraz:

<tag>([^<]+)</tag>

Náhrada:

<tag>nový text $1 další nový text</tag>

Vymýšlení a testování regulárních výrazů

Pro vymýšlení a testování regulárních výrazů existuje velké množství různých programů a webových aplikací. Nicméně já mám oblíbený program RegexBuddy, který krom ostatního pomáhá i s implementací regulárního výrazu ve zvoleném jazyce.

Prostředí programu RegexBuddy.Více o tomto programu na webu www.regexbuddy.com.

Instalace .NET Framework 4 – snadněji to snad už nejde

Nyní se bavím instalací .NET Frameworku 4 na všechny naše testovací a produkční servery. Musím naznat, že je to opravdu příjemná práce. Po stažení webového instalačního balíčku a jediném odsouhlasení licenčních podmínek, je již vše v moci instalátoru a to i volba správné verze pro 64 bitový nebo 32 bitový server.

Pak se už jen můžeme dívat na průběh stahování a instalace .NET Frameworku 4. Po ukončení instalace je nezbytný restart serveru ke kterému budeme vyzváni a .NET Framework 4 je nám plně k dispozici.

Knihovny .NET 2.0 v prostředí .NET 4.0

Dnes jsem se rozhodl jeden WinFormový projekt přepnout do .NET 4.0 z důvodu využití nové funcionality v parametrech motody a to "Výchozí hodnata parametru". Toto se mi hodilo při projektování jedné třídy a tak jsem si řekl proč to nezkusit. Vše bylo OK až do okamžiku překladu projektu, respektive řešení, které se skládá z více projektů. Překvapila mě chyba tato chyba:

FileLoadException: Mixed mode assembly is built against
version 'v2.0.50727' of runtime and cannot be loaded in the 4.0 runtime without
additional cunfiguration information.

Chyba se vztahovala ke knihově třetí strany, kterou jsem nemohl překompilovat po .NET 4.0. Řešetí této situace je poměrně jednoduché. Stačí upravit app.config daného projektu a to takto:

<configuration>
 <startup useLegacyV2RuntimeActivationPolicy="true">
  <supportedruntime version="v4.0"/>
 </startup>
</configuration>

A vše jako zázrakem začne fungovat.