Chapter c = Book.Chapters.GetLast(); Book.Chapters.Count.ToString() + “. fejezet – ” + c.Title;

Chapter XIII. Monitoring, Deploying, and Caching Applications (Alkalmazás felügyelet, telepítés és gyorsítótárazás)

Elnézését kérek, de betegszabadság miatt nem üzemelt a szolgáltatás! Nem mintha már sokkal jobban lennék, de a blog nem várhat

Szerintem az Application Deploymenthez szervesen hozzá tartozik a fordítás(compilation) is. Az egyik legfontosabb újdonság a Visual Studio 05-ben, hogy már ő is az MSBuild-ot használja. Ennek is köszönhető a VB6-ból visszaköszönő Edit and Continue modell, ami annyit takar, hogy ha futtatás közben szerkesztjük valamely oldalunkat, nincs szükségünk újrafordításra, egyszerűen csak frissíteni kell az oldalt és máris az új verziót érhetjük el. Ehhez hozzájárul az is, hogy egy Temporary ASP.NET mappába fordulnak az oldalak.
A precompilation-nél (előfordításnál) van egy olyan lehetőségünk is,-amelyet a könyv nem részletez-, hogy az aspx fájlokból aspx.compiled fájlokat készítsünk. Ez azért jó, mert ilyenkor minden előre lefordul, így a forráskódunkat nem módosíthatják a szerveren. Bár van arra is lehetőségünk, hogy megőrizzük a frissíthetőséget, vagyis csak a kódjaink forduljanak le, de az aspx fájlok, a témák, mesteroldalak, stb-k nem!

A Monitorozásnál volt szó a Performance Counterekről, hogy ezekkel milyen jól lehet teljesítményt meg mi egymást mérni. Igazándiból annyi mérhető dolog  áll rendelkezésünkre, hogy akármit ki lehet belőlük hozni. Az ASP.NET objektumcsoportokon kívül a .NET CLR csoportokban is nagyon sok hasznos és még több használhatatlan mérő áll rendelkezésünkre.
Ezeket persze felhasználhatjuk akár saját alkalmazásainkban is! Amíg nem volt ASP.NET–ben Membership kezelés, addig nekünk kellett megírni azt, hogy hányan is figyelik jelenleg az oldalunkat. Erre persze 1001 megoldás van, de most egy Performance Counteres példát szeretnék veletek megosztani:
Húzz a webform-ra egy performancecounter-t és állítsuk be a következőket:
performanceCounter1.CategoryName = "ASP.NET Applications";
performanceCounter1.CounterName = "Sessions Active";
performanceCounter1.InstanceName = "__Total__";
Ezek után a performanceCounter1.RawValue tulajdonságán keresztül tudjuk elérni az aktuális látogatok számát. Minden usert csak egyszer fog számolni, bár hányszor is frissíti az oldalt, hiszen mindig csak 1 munkamenet-állapot fog hozzátartozni. Persze, ha egyszerre több browser-rel böngészi az oldalunkat a kliens, akkor a szám nőni fog. Ilyenkor esetleg érdemes lehet kódból megvizsgálni azt, hogy a kérések egy ip címről érkeznek-e (Request.UserHostAdress).
A alkalmazás felügyeletnél sajnos a könyvből kimaradt az, hogy hogyan is lehet naplózni SQL Server-t használva, ezért íme egy oldal, ahol ez le van írva:
http://weblogs.asp.net/drnetjes/archive/2004/12/09/279101.aspx
Illetve itt egy elég szép gyűjtemény a HealMonitoring-gal kapcsolatos témákról:
http://msdn2.microsoft.com/en-us/library/ms178701.aspx

Az alkalmazás cachelést szerintem nem a végére kellett volna hagyni a könyvnek, inkább a közepe fele kellett volna megejteni.
Egy érdekessége az ASP.NET cachelésnek, hogy akár teljes user controlokat is képesek lehetünk gyorsító tárazni, ugyanúgy, mint az „sima” Output Caching-nél. Ismét a trace használatát javaslom, ennek a mechanizmus a megértéséhez.
Visszatérve az SQL szerver-hez, szerintem hasznos az SqlDependecy (adatbázis függőség) használata, amellyel utólag gyorsíthatunk alkalmazásunkon. Triggerek (kioldók) segítségével történik az adatok konzisztenciájának figyelése. Weben igazán használható leírást nem találtam, amiben minden benne lett volna hozzá, így majd a devportal-ra egy tutorialt fogok ki tenni erről valamikor.

 

Utcsó előtti fejezet

Chapter XII. Creating ASP.NET Mobile Web Applications (Mobil webalkalmazás készítés)

Mobil webalkalmazás fejlesztés szerintem néha nehezebb, mint a „sima” ASP.NET fejlesztése. Hiszen ugyanazokat itt is meg tudjuk csinálni, mint WebForms-nál, csak itt még egy jó pár szabályhoz alkalmazkodni kell (nincs süti; minél kevesebb kép; egy sor, egy vezérlő, stb..) Ráadásul még egy másik Framework-kel is dolgozunk, nem a .NET Frameworkkel, hanem a .NET Compact Framework-kel. Ennek köszönhetően sok olyan dolog elérhető, ami a "normál" keretrendszer alatt nem, pl.: Telefon, Sms, Wifi, Direct3d támogatás, Message Queuing – MSMQ (ez normál rendszerben is elérhető, de mobil eszközöknél lényegesebb).
Az MSMQ segítségével WinCe alatt a programok képesek egymással kommunikálni hálózaton keresztül.
Egy érdekes dolog az, hogy amikor telepítjük a VS05-öt, akkor nem csak a Compact Framework 2.0 települ, hanem a Compact Framework 1.0 SP3 is! Illetve még szintén települ a MS SQL Server 2005 Mobile [ENU] Developer Tools. Ez egy „eszköztár” az SQL Server 2005 Compact Edition adatbázis szerverhez. (A 2005 Compact Edition elődje az SQL Server CE 2.0 volt). Bővebb infó:
http://www.microsoft.com/sql/editions/compact/default.mspx

Itt egy oldal, ahol össze van szedve a Compact Framework 2.0 újdonságai az 1.x-es változathoz képest. 
http://www.dotnet-guide.com/new-features-in-dotnet-compact-framework2.html
Itt pedig nagyon sok jó tutorialt találhattok (van pár játék is:D)
http://www.codeproject.com/netcf/
http://samples.gotdotnet.com/quickstart/CompactFramework/doc/sqlcemergereplication.aspx

Nem szabad azt hinnünk, hogy a termék palettának itt vége lenne, hiszen még van Micro Framework is! A .NET Micro Framework-öt kis, beágyazott eszközökre készítették, ami a .NET környezet megbízhatóságát és hatékonyságát nyújtja. Bővebb infó:
http://msdn2.microsoft.com/en-us/embedded/bb267253.aspx
Amint a bejegyzésen is látszik, én nem túl sokat foglalkoztam Mobil alkalmazás fejlesztéssel, ezért érdemi okosságokat ma nem tudtam mondani…

 

string s = Convert.ToBinary(3).ToString(); Label.Text = s + Resources.Tilte_Sufix;

Chapter XI. Implementing Authentication and Authorization (Azonosítás és jogosultságkezelés beépítése)

 

A felhasználó azonosítóskor a Login vezérlőt használjuk, elfelejtett jelszó esetén pedig a PasswordRecovery controlt. Van egy olyan lehetőségünk, hogy a login vezérlőnél egy linket automatikusan hozzáfűzzön a .NET a control-hoz, amely a jelszó visszaállító oldalunkra irányít. Ehhez a PasswordRecoveryText, PasswordRecoveryUrl-t kell beállítani.
Regisztrációhoz ugyebár a CreateUserWizard-ot használjuk. A könyvben úgy írták meg a regisztráció utáni átirányítást, hogy a ContinueButtonClick eseményében meghívták a Redirect tagfüggvényét a Server-nek, pedig van egy sokkal egyszerűbb megoldás. A CreateUserWizard-nak egy olyan tulajdonsága, amely ugyanezt a célt szolgálja, ez a ContinueDestinationPageUrl. Szerintem a LoginCreatedUser-t érdemes false-ra állítani, ilyenkor nem fogja automatikusan az új usert beléptetni. Persze nem árt, ha a két tulajdonság összhangban van, bár ha védett oldalra akar elnavigálni autentikáció nélkül a user, akkor úgyis a Login page-re dobja vissza.
Egy hasznos és érdekes tulajdonsága a Login Wizard vezérlőknek, hogy tudunk hozzájuk adni saját step-et (lépés), illetve létre tudunk hozni belőlük template controlokat! Ezeket a smart tagekben érhetjük el (Add/Remove WizardSteps, Convert To Template) A sablonok egyik legkézenfekvőbb előnye az, hogy nem kell a Login Wizard vezérlők tulajdonságait böngészni és ott „honosítani”, ha nem használunk skin vagy resource fájlt, hanem egyszerűen a template generáláskor létrehozott címkéket kell csak átírni. Illetve ilyenkor természetesen módunkban áll átrendezni, átméretezni a cuccot, ha például túllógna az egyik, stb.
Mindegyes login vezérlőnek töménytelen sok tulajdonsága van, amelyek főleg a kinézetet testreszabására szolgálnak, illetve működésüket befolyásolják. Használatuk közben egyszerűen rá lehet jönni, mi mire is való!

Az autentikációs módoknál van arra lehetőségünk, hogy Passport alapú azonosítást használjon rendszerünk. Ezzel mindösszesen annyi a baj, hogy maga az MS Passport mint elgondolás megbukott, mivel nem szívesen adták meg az emberek személyes adataikat az MS számára, amelyeket a cég tárolt egy központi adatbázisban. Az egész dolgot újragondoltál és ennek köszönhetően a .NET Framework 3.0-ban már a CardSpace megoldás lesz elérhető. (Régebben InfoCard-nak is hívták). Itt az alapelgondolás változott meg, vagyis nem egy központi szerveren tároljuk az adatainkat, hanem a sajátgépünkön, és úgymond válogathatunk a „névjegykártya albumunkban”, hogy szeretnénk-e használni vagy nem, és ha igen akkor melyiket. Akinek felkeltettem az érdeklődését, nekik tudom ajánlani a következő oldalt:
http://en.wikipedia.org/wiki/Windows_CardSpace

Bár a könyvben erőteljesen javasolják a web.configban a location használatát, ha szigorítani szeretnénk egy adott mappára a belépési szabályokat, szerintem inkább válasszuk azt a megoldást, hogy az egyes subfolderekhez (almappákhoz) külön-külön tartozzon egy web.config.

Egy régi bejegyzésben írtam a SiteMapNode-okról, hogy lehetőségünk van jogosultságokhoz kötni őket a roles attribútummal. Ha már authorizációról is szól ez a fejezet, akkor muszáj, arról is néhány szót ejtenem, hogy mi a helyzet akkor, ha saját SiteMapPorvider-t definiálunk. Szerencsére rendelkezik beépített jogosultság kezeléssel, ezt csak „aktiválni” kell, vagyis a securityTrimmingEnabled –t true-ra kell állítani. Mélyebb ismerkedéshez ezt az oldalt ajánlom:
http://blogs.msdn.com/dannychen/archive/2006/03/16/553005.aspx

 

string s=”víz”; s.Replace(“v”,”t”); s.ToInt32() + “. fejezet”; ;-)

Chapter X. Globalization And Accessibility (Globalizáció és Hozzáférhetőség)

 

A lokalizáció egy nagyon hasznos eszköz, ahhoz, hogy oldalunkat szélesebb körben látogassák. Érdekes dolog az, hogy néhány összetett vezérlő képes az automatikus lokalizációra, vagyis ezen kontrolok tulajdonságaihoz nem feltétlenül kell újabb resource bejegyzéseket tennünk a .resx fájlokba. Ilyen például a Calendar (naptár) vezérlő. A vezérlő nem csak a hónapok illetve napok nevét „honosítja”, hanem a hét első napját is beállítja! (Property: FirstDayOfWeek)
Azért írtam, hogy nem feltétlenül szükséges, mert ha használunk tooltip-eket, akkor azokat illik átírni!
A Culture illetve UiCulture-t, ha kézzel szeretnénk beállítani, akkor sok lehetőségünk van. Én az 1.X-es .NET Framework alatt ezt használtam: (ez WinForms alatt is működik, a könyvben lévő megoldás, ha jól tudom csak WebFormoknál)
using System.Threading;
using System.Globalization;
…
Thread.CurrentThread.CurrentUICulture = new CultureInfo("fr");
Thread.CurrentThread.CurrentCulture = CultureInfo.CreateSpecificCulture("fr");

Érdemes egyszer megnézni azt, hogy egy ilyen resx fájl, hogyan áll össze. Vagyis Design módból Code módba kell váltanunk. Ezt úgy tudjuk megtenni, hogy a Solution Explorerben jobb klikk a resx fájl, helyi menüben View Code menüpontot választjuk.
Van még egy objektum, amely képes kezelni a kultúra specifikus resource fájlokat, ez a ResourceManager. Nem csak XML alapú fájlokat képes kezelni, hanem Assembly fájlokat (dll) is. A GetString() tagfüggvénye segítségével tudjuk kinyerni a paraméterként átadott kulcshoz tartozó értéket. Az alábbi oldalon eléggé sok hasznos infót találhattok a ResourceManager-ről:
http://www.openmymind.net/localization/

Illetve még szeretném felhívni a figyelmeteket egy hasznos Refactor kiegészítésére, ami a resource fájlokkal kapcsolatos, ez a Resource Refactoring Tool:
http://www.codeplex.com/ResourceRefactoring

A fejezet második részéhez, a Configuring Accessibility –hez, nem tudok mit hozzá fűzni, mivel én az ASP.NET ezen részével ez idáig nem foglalkoztam, maximum beállítottam az alternate text tulajdonságokat.

iikszedik fejezet

Chapter IX. Customizing and Personalizing a Web Application (Webalkalmazás egyénire és tesztreszabása)

 

A tegnapi blog bejegyzésben elfelejtettem valami fontosat leírni, így most pótolom. A Web.config fájl szerkesztése ASP.NET 1.x alatt jóval nehezebb volt, mint a 2.0-ás nagytestvére alatt, ahol már rendelkezésünkre áll az IntelliSence. Csak, hogy ne legyen egyszerű az életünk az IS nem mindig érhető el, ezért néha be kell vetnünk egy kis trükköt.
Ha a web config 2. nem komment sorában ezt látjuk:
<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
akkor az IS, csak annyit fog felajánlani, hogy CDATA-t(egyszerű szöveg), megjegyzést, feldolgozandó utasításokat szúrhatunk be a konfig fájlba. Ilyenkor annyi a teendőnk, hogy kitöröljük a configuration element-ből a névtérre való hivatkozást (xmlns=…). Ezek után már rendeltetésszerűen fog működni az IS. Ha mi magunk hozzuk létre a web.config fájlt (sol epx/add new items/web conf), akkor ezzel a problémával nem fogunk találkozni, de ha például Web Administration Tool-lal turkálunk a konfigurációs fájlban, akkor be fog kerülni az xmlns attribútum.

Akiket érdekel az XML, azoknak tudom ajánlani a következő oldalt, ami jó betekintést nyújt mire is képes ez a nyelv:
http://www.prog.hu/cikkek/katalog/2110/XML.html
Természetesen mivel cikksorozatról van szó, ezért eléggé rohamtempóban sulykolják az olvasókba az infókat. Az XML elmélyítéshez a Michael J. Young által írt XML Step by Step könyvet ajánlom!

A mester oldalakhoz (master page) annyi hozzáfűzni valóm van, hogy ha a mester oldalra jobb egér gombbal kattintva a helyi menüből az Add Content Page menüpont választjuk, akkor létre tudunk olyan oldalalkat hozni, melyek használják a mester oldalunkat. Nem egy olyan eget verően nagy okosság, de néha hasznos tud lenni. Ami kicsivel érdekesebb dolog az az, hogy ha a Master Page-ünkön több ContentPlaceHoldert helyezünk el, de nem mindegyik oldalon használjuk őket, akkor a nem használtakat a Masterének nyilvánítja, az általunk módosítottakat pedig Custom-nek. Ami számomra kicsit meglepő, hogy a mester oldalakat használó content oldalhoz, ha hozzá akarunk adni olyan content-et, melyhez nem tartozik ContentPlaceHolder a master page-n, akkor meg se fogja jeleníteni az oldalon. Még akkor se, ha mondjuk szándékosan kihagyjuk a ContentPlaceHolderID attribútomot.
A profile-hoz nincs mit hozzá fűznöm, mivel baromi egyszerű használni, és néha érdemes is ebben tárolni a user specifikus adatokat Session helyett.
A webpartok azok a vezérlők, amelyek mindig tudnak újdonságot hozni, hiszen még messze nem tudjuk kihasználni a bennük rejlő lehetőségeket. A webpartokhoz már tettem egy pár megjegyzést az előző blog bejegyzéseimben, így most csak egy könyvet ajánlanék, ami nagy segítség lehet a bennük lévő dolgok kiaknázásához: Peter Vogel – Professional Web Parts and Custom Controls with ASP.NET 2.0

Nyócadikk fejezet

Chapter VIII. Programming the Web Appliction (Webalkalmazás programozása)

A try/catch blokknak van egy olyan érdekessége, hogy nem csak 1 catch ág lehet, hanem több is. Ez például akkor lehet hasznos, ha a try blokkban egy olyan függvényt hívunk meg, ahol például, ha rossz paramétert kap, akkor dob egy kivételt. (if(s==null) throw new ArgumentNullException();) Ezt a exceptiont pedig nem ugyanabban a catch blokkban kezeljük le.
A web.config fájl tárgyalásánál, amikor táblázatba van összegyűjtve, milyen osztályokat kell használnunk az egyes ConfigurationSection-ökhöz, akkor én tettem volna még egy harmadik oszlopot is, ahol röviden leírás lett volna, az adott a szekcióban mit is lehet konfigurálni. Bár elég beszédes neveket kaptak az egyes szekciók, de szerintem nem mindenki tudja fejből, hogy például a Trust vagy a HealthMonitoring szekciók mire valók, ezért itt egy link, ahol nagyjából össze van szedve mi mire is jó:
http://www.sitepoint.com/article/web-config-file-demystified

Kicsit még mindig értetlenül állok a dologhoz, hogy ebbe a fejezetbe minek kellett belevenni az egyedi http kezelőket, vagy ha már belevették, akkor miért csak ennyit írtak róla.
Szerintem egy nagyon érdekes dolog az, hogy miért is csak 1 tulajdonságot és egy metódust kell megírnunk, ha saját HttpHandler-t hozunk létre. Ennek oka, hogy az IHttpHandler interface, összesen ennyiből áll „belülről”:
void PorcessRequest(HttpContext ctx);
bool IsReusable{get;}.
Még fontosnak tartottam volna a Generikus kezelőket is (ASHX fájlokat), aminek nagy előnye, hogy sem az IIS-ben, sem a Web.Config-ban nem kell beregisztrálni.
Illetve ha már HttpApplication-ről (global.asax) képesek voltak írni két sort, akkor a HttpModule-okról is ejthettek volna pár szót. Bár valószínűleg ezek azért nem kerültek bele könyvbe, mivel nem rész a web-es MCP vizsgának, ha jól tudom.

A fejezet második részében szerintem eléggé jól meg lehet ismerkedni a Page objektummal. De azért szeretnék egy egyszerű példakódot mutatni arra, hogy a sok Path/Url metódus mire is jó:
string u = ”~/upload/videos/DataSetUsing.wmv”;
 u = Request.Url + u;
 u = u.Replace(Request.RawUrl.ToString(), String.Empty);
 u = u.Replace("~", Request.ApplicationPath.ToString());
A végeredményben valami hasonlót kapunk pl.: http://msiskola.jedlik.hu/aspnet/upload/videos&#8230; Nekem erre azért volt szükségem, mert az adatbázisban a tildés(~) verzió volt eltárolva, amit tudott értelmezni az ASP.NET. De amikor e-mailbe lekérik valamelyik mellékletet, akkor már manuálisan kell összehegeszteni a teljes elérési címet.
A másik dolog, amire felhívnám a figyelmet az a Server.Mappath metódus, amely megmondja a virtuálismappa fizikailag, hol is helyezkedik el. Ez hasznos lehet, akkor, ha például egy access adatbázisra szeretnénk hivatkozni, mondjuk a kapcsolati sztringünkből, kódból, mivel relatív elérési utat nem adhatunk meg. Futásidőben ilyenkor be fog helyettesítődni. Használatára egy egyszerű példa:
string ConnString;
ConnString= @"Provider=Microsoft.Jet.OLEDB.4.0; User Id=; Password=; Data Source=" + Server.MapPath("~/databases/Nwind.mdb");

Ja és egy kicsit kötözködnék, mivel nem csak a Page.Head.Title-ön keresztül lehet elérni az oldal fejlécét, hanem a Page.Title-ön is!

int i=6; i++; Response.Write(i.ToString() + “. fejezet”);

Chapter VII. ASP.NET State Managment (ASP.NET Állapot kezelés)

A kliens oldali állapotmentés jó dolog, addig -mint ahogy a könyvben is írták- amíg fontos és felhasználó specifikus adatokat nem tárolunk benne. Hiszen ezek könnyen módosíthatók, mivel a kliens gépén vannak eltárolva. A ViewState-ről írták, hogy alapban kódolva van. Base64 kódolást használnak, ami azt jelenti, hogy egy rosszabb gépen is másodpercek alatt visszafejthető! Amit a web.config fájlban illetve a Page direktívában betudunk állítani kódolás, az már 3des, amit kicsit több időbe kerül feltörni.
Az ASP.NET 1.X esetén a ViewState-nél még volt egy olyan érdekes dolog, hogy nem elég az, hogy minden vezérlőnek volt, de még a Page objektumnak is, vagyis magánál a weblapnál is ki kellett kapcsolni az ViewState-t (EnabledViewState=False), ha nem használtuk. ASP.NET 2.0-nál helyére bekerült a Document tulajdonság ablakába az EnabledSessionState, amit pedig a könyvből ismerhetünk. Az összesen állapotmentésre szolgáló objektum valójában úgy működik, mint egy szótár, vagyis Dictionary objektum. A ViewState mivel nem tördeli az adatokat, hanem összekonkatenálja, ezért valójában StateBag objektumokat tudunk elérni a ViewState objektumon keresztül (pl.: this.ViewState["dic"]).
Na így szerintem teljes lett a kliens oldali állapotmentés rész is

A szerver oldali állapotkezelés, és itt főleg munkamenet-állapotra (Session) gondolok, kicsit le lett egyszerűsítve a könyvben. Mindenegyes különböző klienstől érkező kéréshez a szerver létrehoz egy egyedi munkamenetet. Ezt tudjuk kezelni a Global.asax fájlon belül: Session_start, Session_end… Mivel mindenkinek van saját munkamenet állapota eltárolva, ezért lehet itt felhasználó specifikus adatokat tárolni. Legismertebb példaalkalmazás, amivel reprezentálni szokták a Session-t, a webshop-os bevásárlókocsi. Hiszen a kulcs-érték párnál az érték egy objektum, tehát lehet akár DataTable vagy ArrayList. Adat kinyerésekor pedig emiatt van szükség kasztolásra vagy magyarosabban típus kikényszerítésre.
Míg a sütik leírták, hogyan kell eltávolítani a sütieinket, addig a Session-nél ez kimaradt. Pedig fontos, hiszen ezzel erőforrást szabadíthatunk fel! A Session-nek is –mint majdnem objektumnak- van dispose metódusa, ezáltal az összes kulcs-érték adatunk elveszik. Mivel a Session egy dictionary objektum, ezért kezelhetjük úgy, mint egy gyűjteményt. Vagyis a Session.Remove("key") vagy Session.RemoveAt(index) tagfüggvények segítségével tudunk eltávolítani elemeket, vagy pedig az összeset a RemoveAll() metódussal.
Egyszer mindenféleképpen ajánlom azt, hogy nézzük meg úgyis a Session működését, hogy be van állítva a nyomkövetés (Trace). Alap esetben ne csak a Session részt nézzük, hanem a Cookie-s részt is, majd állítsunk be cookieless módot és utána is csekkoljuk le!

Hatodik fejezet

Chapter VI. Input Validation and Site Navigation (Érvényesítő vezérlők és oldal navigáció)

 

Az érvényesítő vezérlőkről igazándiból nem túl sokat lehet írni, ezért nem is maradhat ki túl sok dolog. Amit én mondjuk még külön tárgyal volna az a ValidationSummary vezérlő. A könyvben megtudhatjuk, hogy ez mire is jó, illetve azt is, ha ezt használjuk, akkor a validator vezérlők Text tulajdonságához kell megadni a hibaüzenetet és az ErrorMessage property-nél pedig csak egy *-ot szokás beállítani. A ValidationSummary 3 olyan tulajdonságát érdemes még megjegyezni, amikkel a hibaüzenetek megjelenését tudjuk szabályozni. Íme:
– DisplayMode: List|BulletList|SingleParagraph
Itt azt tudjuk beállítani, hogy amennyiben több hiba is van az oldalon, akkor listaként, felsorolásként, vagy egyszerű bekezdésekként jelenítse meg a hibajelzéseket.
– ShowSummary: True|False
Egyenlő a visible tulajdonsággal
– ShowMessageBox: True|False
Ha ezt igazra állítjuk, akkor a hibaüzeneteket egy windows-nál gyakran látott üzenetablakban fogja megjeleníteni. Természetesen itt is a DisplayMode-nál megadott formában!

Az oldalak közötti navigációs részhez már kicsit több hozzáfűzni valóm van. Amit már korábban is felvetettem problémát a Menu, Treeview vezérlők bemutatásánál, -vagyis a SiteMap osztály használata- itt végre ki lett javítja úgy-ahogy. A SiteMapNode -oknak van egy olyan hasznos attribútuma, amelyet úgy hívnak, hogy roles. Bár igaz még a könyvben nem volt szó az ASP.NET 2.0 új hitelesítési és jogosultság-kezelő rendszeréről, de azért érdemes már itt megemlíteni. Tehát a roles segítségével azt tudjuk szabályozni, mely userek, mely menüpontokat láthatják. Például nem biztos, hogy dolog, ha egy egyszerű felhasználó látja az adminisztrációs felülethez tartozó linkeket. Ilyenkor két dolgot tehetünk, vagy azt, hogy két külön sitemap fájlt készítünk, külön az admin részhez, külön az oldalhoz, vagy pedig használjuk a roles attribútomat. Ha azt állítjuk be egy SiteMapNode-nál, hogy roles=”*”, akkor ezt bárki láthatja. Ha azt állítjuk be például, hogy roles=”editors”, akkor csak editorok láthatják, és nem kell nekünk ezzel külön szenvednünk kódban, hogy megvizsgáljuk az IsInRole függvény segítségével.
A SiteMap Class-nek van sajnos egy nagy hiányosságai, még pedig az, hogy csak statikus adatokkal tud dolgozni. Vagyis, ahhoz hogy az olyan oldalak között tudjunk navigálni, amiknek a címe dinamikusan jön létre (pl.: aspx?id=35d-7465dsa…), ahhoz kénytelenek vagyunk felül definiálni a SiteMapProvider-t. Erről, majd fogok írni tutorialt a devportal-ra, de nagyon röviden összefoglalom mit is kell csinálni:
– Web.Config-ban új SiteMapProvidert kell létrehozni:
<siteMap defaultProvider="NewProvider" enabled="true">
<providers>
<add name="NewProvider" type="System.Web.XmlSiteMapProvider" siteMapFile="~/web.sitemap"/>

…
– Létre kell hozni egy új osztályt, amelyben felül definiáljuk a SiteMapProvider-t:
public class sitemap : StaticSiteMapProvider
  {
– Két függvényét kell mindenféleképpen felül definiálnunk:
— BuildSiteMap()
— GetRootNodeCore()

Ha TreeView vezérlőnél szeretnék szintén dinamikusan generált linkekből létrehozni egy fastruktúrát, akkor nem feltétlenül kell a SiteMapProvidert felül definiálni, elég ha a TreeNode-kat dinamikusan hozzuk létre kódból. Na jó, ennyire azért nem egyszerű, itt is kell egy kicsit trükközni, de hagyok valamit a cikkbe is:D
Mára utolsó megjegyzésként egy hasznos feature-re szeretném felhívni a figyelmet. Biztosan sokszor találkoztunk már interneten olyan oldalakkal, ahol az oldalt görgetni kellett a hossza miatt, és ha pl.: a végén egy gombra rákattintottunk, akkor frissítés után ismét az oldal elején találtuk magunkat. Az ASP.NET 1.X-es verzióban a scroll pozíció megjegyzésére a Page direktívában a SmartNavigation-t kellett true-ra állítani. Csak, hogy ne legyen egyszerű az élet ezt ASP.NET 2.0 alatt átnevezték, egy sokkal szebb névre:

 

 

MaintainScrollPositionOnPostback

Mennyivel jobb lett ettől a világ

Ötödik fejezet

Chapter V. Creating Custom Web Controls (Egyéni Web kontrol készítés)

 

Ez a fejezet volt az első, amely olyan dolgokról is írt, amiről még ez idáig én nem olvastam soha. Konkrétan a templated control-ra illetve a template user control-ra gondolok. Bár elsőre nem túl sok értelme látszik annak, hogy pluszba kódoljunk, csak azért, h az oldal designere ne nyúljon hozzá a user controlunk, de nem is ezen van a lényeg. Az újrahasznosíthatóság sokkal meggyőzőbb érv, mint az, hogy nem tudjuk fejlesztési időben, hogyan fog kinézni a felhasználói vezérlőnk.
Ehhez a fejezet csak néhány kiegészítést, megjegyzést tennék, mert szerintem ez a fejezet kifejezett jól lett felépítve.

Ha user controlokat akarunk használni példuál egyes webpart zónákban, akkor alap esetben a zóna fejléce az lesz, hogy Untitled [i] (i természetes szám). Ilyenkor az a megoldás, hogy a source nézetben a user control tag-hez beírjuk title=”MyNamedWebPartZone”. Az érdekesség az egészben az, hogy ezt az IntelliSence fel se ajánlja, hogy lenne ilyen attribútuma, így zöld hullámos vonallal fogja aláhúzni a VS, de működik.
A Custom Control készítésnél, tehát amikor egy adott vezérlőből indulunk ki, én valahogy jobban kihangsúlyoztam volna azt, hogy ilyenkor csak hozzáadni tudunk + feature-öket. A könyves példában a LabeledTextBox-nál kicsit megtévesztő lehet a név, hogy ez valójában egy kontrol -csak hülye nevet választottak neki(címkézett beviteli mező)-, nem pedig egy composite control, ahol van egy label illetve egy textbox.
Szerintem a custom control-nál túl lett magyarázva az egyes attribútumok használata. A ToolboxBitMap, illetve ToolboxData egy-egy sorban elmagyarázható. Hamár attribútumokról és hamár webpartokról volt szó akkor…, lehetőségünk van webpartoknál arra is, hogy az egyes webpart zónákban lévő vezérlők bizonyos tulajdonságait megváltoztassa a kliens. Ezt ugyebár a AppearanceEditorPart segítségével teheti. Sajnos innen csak olyan adatok érhetőek el, mint az elhelyezkedés, stílus, stb., tehát semmi konkrét használható tulajdonság. Ilyenkor érdemes létrehozni egy saját webpart controlt, amelyben deklarálunk például egy hyperlinket, majd hozzá adunk tulajdonságokat, amelyekkel beállítjuk a Text illetve NavigationURL tulajdonságait. Így még mindig nem lesz elérhető PropertyGirdEditor-ból, mert meg kell még hozzáadnunk a következő attribútumokat:
[Personalizable(), WebBrowsable, WebDisplayName("Megjelenő szöveg")]
public string DisplayName
{
  get
…

Amikor egy custom control-nál felül definiáljuk a Render metódust (override Render), akkor paraméterben kapunk egy példányt a HtmlTextWriter osztályból. Ahhoz, hogy ne kelljen teljes tag-eket beírnunk többfajtaképpen is meg úszhatjuk a sok gépelést. Az egyik, amit a könyvben is láthattunk: output.WriteFullBeginTag(”span”) illetve output.WriteEndTag(”div”). Egy másik módja az hogy a HtmlTextWriter osztály RenderBeginTag tagfüggvényét használjuk és paraméterként egy HtmlTextWriterTag objektumot adunk meg. Íme egy példa:
output.RenderBeginTag(HmtlTextWriterTag.Font)
output.AddSytleAttribute(HtmlTextWriterStyle.Color, ”blue”)
output.RenderEndTag()

Valamivel kényelmesebb, mint a Write tagfüggvénnyel szenvedni és a zárótag-es tagfgv. nem is vár paramétert!

Negyedik fejezet II. felvonás

Chapter IV. Using ADO.NET and XML with ASP.NET (ADO.NET és XML használta ASP.NET-nél)

Folytatva a múlt héten megkezdett fejezet elemzésemet 3 kiegészítést teszek még az ado.net-hez, majd utána rátérek az XML-es részére a fejezetnek.

A DataSet az az objektum, amely úgymond az ADO.NET lelkét adja és erre 5 oldalban elintézik (típusos adatkészletet nem bele számolva). Nem célom, hogy az ADO.NET-et teljes mélységében való ismertetése az olvasóval, így csak néhány érdekességre hívnám fel a figyelmet a dataset-tel kapcsolatban.

Íme egy ábra, mely jól szemlélteti a dataset-hez kapcsolódó objektumok elhelyezkedését az ado.net-ben: http://msiskola.jedlik.hu/aspnet/upload/others/ADO.NET.gif
Van egy eléggé érdekes tulajdonsága a DataSet-nek, ez a DefaultViewManager. Ez konkrétan arra szolgál, hogy az adatkészletben tárolt adatok testreszabott nézetét érjük el. Nézetek segítségével szűrhetünk, kereshetünk, mozgathatunk adatokat. Általában ezt szoktuk használni, amikor adatforrást határozunk meg: MyDS=MyDataTable.DefaultView. (A defaultviewmanager nem egy az egyben egy dataview, de eléggé sok köze van hozzá)
Az adatkészlet feltöltésénél ugyebár a DataAdapter fill metódusát használjuk. Ennek van egy igen fontos túlterhelt paraméterezése, amely sokszor hasznos tud lenni. Íme a szintaxis: Fill( DataSet myDS, int startRow, int numofRows, string DTname). Ez arra szolgál, hogy a select lekérdezés eredményeinek csak egy bizonyos részével akarjuk feltölteni az adatkészletünket. Először megadjuk az adatkészletet, majd utána azt a számot, ahányadik rekordtól kezdve tárolja le a következő numofRows darab rekordot az alábbi (DTname) adattáblába. Ennek eléggé olyan léptetés szaga van, mivel arra is szokták használni. Mivel a GridView-n, DetailsView-n, illetve FormView-n kívül nem támogatott alapból a léptetés egyetlen adatbázishoz köthető vezérlőnél sem, ezért ezeknél kénytelenek vagyunk mi így megírni ezt.
A DataSet-eket adatmódosításra is lehet használni, illetve megszorítások, kényszerek kezelésére. A DataAdapter objektumnak van egy FillSchema() nevű tagfüggvényét pontosan erre találták ki. A függvény meghíváskor meg kell adnunk az adatkészletet, illetve egy SchemaType típust. A SchemaType felveheti a Mapped illetve a Source értékeket is. A Mapped figyelembe veszi a táblaleképzéseket és ezek alapján átszerkeszti a DS sémáját. A Source figyelem kívül hagyja a táblaleképzéseket, magyarul, mintha a sima Fill tagfüggvényt használnánk.
Több okosságra most nem hívnám fel a figyelmeteket a datasettel kapcsolatban, akit érdekel a dolog neten biztosan talál róla még jó sok leírást

Az adatkapcsolatot leíró sztringekhez, annyit fűznék hozzá, hogy van egy olyan oldal, ahol a különböző gyártóktól származó adatforrásokhoz tartozó connectionstring-ek felépítéseit tárolják. Ez a http://connectionstrings.com oldal.

A könyvben olvashattunk egy eléggé egyszerű példát a ConnString-jeink titkosítására a konfigurációs fájlunkban. Szeretnék, most egy másik példát mutatni, hogyan is lehet ezt meg valósítani kódból, aspnet_regiis használta nélkül.
using System.Web.Configuration;
…
protected void EncryptWebConfigConnString (bool Encrypted)
{
string path = ”\encryptsample”

Configuration config = WebConfigurationManager.OpenWEbConfiguration(path);
ConfigurationSection appSettings = config.GetSection(”connectionStrings”);
if (Encrypted)
{
appSettings.SectionInformation.ProtectSection(”DataProtectionConfigurationProvider”);
}
else
{
appSettings.SectionInformation.UnprotectSection();
}
config.Save();
}

A EncryptWebConfigConnString függvény meghívásánál attól függően, hogy true vagy false értéket adunk át neki paraméternek, titkosítja, vagy visszaalakítja az adatkapcsolat sztringjeinket. A kódból látszik, hogy ez nem csak a ConnString titkosítására alkalmas, hanem bármely más config fájlbeli szekciókra is!
Az adatbázisos rész végére egy hasznos megjegyzést még teszek. Bár az ADO.NET is támogatja a Tranzakciók-kezelést a Transaction objektum segítségével, de sokkal inkább javasoltabb, ha tárolt eljárásban írjuk meg TSQL nyelven!

Az .NET Framework XML-es támogatottsága tényleg zseniális, csak átlag fejlesztő soha nem használja (csak nagyobb cégeknél). Mint ahogy a fejezeten is látszik a többitől eltérően, olyan mintha össze lett volna csapva az eleje. Az összes vezérlőt egyből a fejünkhöz vágják, hozzá 30 új rövidítés illetve kiterjesztés, hogy ténylegesen káosz legyen a fejünkben. Utána megpróbálnak valamennyire rendet tenni a fejünkben, kisebb-nagyobb sikerrel. Például írják, hogy a fejezetben még kitérnek az XmlDocument illetve XmlDataDocument közötti különbségre. Hát… ha nem tudtam volna alapból, akkor a könyvből soha nem tudom meg. Az igazi különbség az, hogy az XmlDataDocument egy kiterjesztése az XmlDocumentnek és kifejezetten a DataSet-tel való munkához találták ki. Itt van egy érdekes cikk, arról, hogy a különböző vezérlők között milyen teljesítménybeli különbségek is vannak:
http://www.vbdotnetheaven.com/UploadFile/daniels70/XslTransformInput04222005055327AM/XslTransformInput.aspx

Bár igaz, hogy a könyv kifejezetten a .NET Framework-ről szól és nem az XML-ről, de én mondjuk még biztos írtam volna az XPath valamennyit. Az XML-ben használt fogalmakról (jól formázott xml dokumentum, dtd, stb) pedig helyes, hogy ne írtak, mivel akkor a könyv kétszer ilyen vastag lenne