2008. december havi bejegyzések

Keresőbarát lapozás

A ListView vezérlőt többek között azért szeretjük, mert korrektül kézben lehet vele tartani a generált HTML kódot. Ha túl sok adatot szeretnénk vele megjeleníteni, akkor tipikusan DataPagert ragasztunk hozzá. De nézte már meg valaki, hogy mit művel a DataPager a generált HTML kódban?

Megmutatom, íme egy egyszerű lista megjelenítés lapozással:

    <asp:ListView ID="ListView1" runat="server" DataSourceID="SqlDataSource1">
        <ItemTemplate>
                <li><%# Eval("Title") %></li>
        </ItemTemplate>
        <LayoutTemplate>
            <ul runat="server">
                <asp:PlaceHolder ID="itemPlaceholder" runat="server" />
            </ul>
            <div>
                <asp:DataPager runat="server">
                    <Fields>
                        <asp:NumericPagerField />
                    </Fields>
                </asp:DataPager>
            </div>
        </LayoutTemplate>
    </asp:ListView>

A lista valóban szép lesz, de a lapozós részből ez kerül az oldalba:

    <div>
        <span>
            <span>1</span>&nbsp;
            <a href="javascript:__doPostBack('ListView1$ctl02$ctl00$ctl01','')">2</a>&nbsp;
            <a href="javascript:__doPostBack('ListView1$ctl02$ctl00$ctl02','')">3</a>&nbsp;
            <a href="javascript:__doPostBack('ListView1$ctl02$ctl00$ctl03','')">4</a>&nbsp;
            <a href="javascript:__doPostBack('ListView1$ctl02$ctl00$ctl04','')">5</a>&nbsp;&nbsp;
            <a href="javascript:__doPostBack('ListView1$ctl02$ctl00$ctl05','')">...</a>&nbsp;
        </span>
    </div>

Biztos megvan ennek is a szépsége, az azonban szinte biztos, hogy a kereső robotok ezeket a linkeket nem fogják bejárni, így nem fogunk tudni ráguglizni a további oldalakon lévő tartalmakra.

A megoldás a QueryStringField tulajdonság alkalmazása a DataPagerben:

    <asp:DataPager runat="server" QueryStringField="Oldal">
        <Fields>
            <asp:NumericPagerField />
        </Fields>
    </asp:DataPager>

Ebbe a tulajdonságba egy tetszőleges sztringet írhatunk, ami meg fog jelenni az URL-ben, például így:

http://localhost/SeoFriendlyPagerSample/Default.aspx?Oldal=5

A HTML kódban pedig így:

    <div>
        <span>
            <span>1</span>&nbsp;
            <a href="/SeoFriendlyPagerSample/Default.aspx?Oldal=2">2</a>&nbsp;
            <a href="/SeoFriendlyPagerSample/Default.aspx?Oldal=3">3</a>&nbsp;
            <a href="/SeoFriendlyPagerSample/Default.aspx?Oldal=4">4</a>&nbsp;
            <a href="/SeoFriendlyPagerSample/Default.aspx?Oldal=5">5</a>&nbsp;&nbsp;
            <a href="/SeoFriendlyPagerSample/Default.aspx?Oldal=6">...</a>&nbsp;
        </span>
    </div>

A dolog nyilván akkor válik igazán érdekessé, ha egy oldalon több lapozó vagy lapozandó vezérlő is van. Ha külön akarjuk kezelni őket, akkor nekünk kell gondoskodni arról, hogy a QueryStringField értéke különböző legyen. Gyanítom, hogy ezért nincs bekapcsolva ez a funkció alapértelmezés szerint…

Ami pedig a rengeteg &nbsp;-t illeti, a NumericPagerField RenderNonBreakingSpacesBetweenControls tulajdonságával ezek megszűntethetőek. Ebben az esetben a CurrentPageLabelCssClass és a NumericButtonCssClass tulajdonságokkal tudjuk az egyes linkek stílusát – például távolságát – megadni.

A kapcsolódó forráskód letölthető az MSDN Kompetencia Központ oldaláról.

 

Amikor a ListView nem az igazi

Az ASP.NET-ben megjelent ListView vezérlő igazi főnyeremény, tud mindent, amit kell, kézbentartható vele a generált HTML kód, ráadásul van hozzá designer támogatás is a Visual Studioban. Csak éppen vízfejűbb, mint bármely más listás adatmegjelenítő vezérlő.

Történt ugyanis, hogy ma hozzá kellett nyúlnom az egyik webalkalmazásunk egyik ASPX oldalához és ha már ott jártam, kicseréltem egy Repeatert ListViewra. Éljen az új vezérlő, ez a jövő, csak jobb lesz nekünk. Hát nem lett. Igen, tudom, ami működik, azon nem szabad változtatni…

Mivel épp azon dolgoztam, hogy az oldal által generált HTML kód minél egyszerűbb és áttekinthetőbb legyen, ezért hamar feltűnt, hogy bizony megnőtt a ViewState. Nem is kicsit. Ráadásul tette mindezt úgy, hogy az egész oldalra ki van kapcsolva a ViewState: EnableViewState=”false”.

Ez kezdett érdekes lenni, hiszen a funkcionalitás nem változott, még a template sem, csak másik vezérlőbe van beágyazva. Letöltöttem Fritz Onion ViewState Decoderét és megnéztem, mi van benne. A ViewState-ben semmi érdekes, ámde a control state-be, ami szintén az __VIEWSTATE rejtett mezőben utazik, bizony került valami a ListView1-től. A control state pedig akkor is ott van, amikor a ViewState ki van kapcsolva. Ez tehát nem bug, hanem feature!

Ezen a felismerésen fellelkesülve elkezdtem méregetni, hogy a különböző vezérlők hogyan viselkednek. Egy táblából válogattam le 145 rekordot és jelenítettem meg különböző vezérlőkben, miközben mértem az oldal és a ViewState méretét. Íme az eredmény:

Page size
(bytes)

Page ViewState length
(character count)

EnableViewState =

true

false

true

false

ListView

185 969

85 785

100 276

92

Repeater

197 324

97 176

100 200

52

DataList

201 065

100 889

100 228

52

DataList RepeatLayout="Flow"

200 121

99 945

100 228

52

GridView

204 048

102 868

101 256

76

A táblázatból az látszik, hogy a ListView szemeteli a legnagyobb ViewState-et még akkor is, ha a ViewState egyébként ki van kapcsolva. Az oldalhoz tartozó 52 karakteres alap ViewState majdnem kétszer akkorára növekszik. Mindez persze csak akkor igaz, ha egyetlen ListView van az oldalon, ha több, akkor példányonként további 40 karakter a sallang.

Persze a másik oldalon ott a ListView óriási előnye: a kézbentartható HTML kimenet. Míg a többi vezérlő span és table tag-ekkel tudta csak beágyazni a template-et, a ListView-nak nincs szüksége ilyen körítésre, tehát csak az kerül a HTML kimenetbe, amit mi beleírunk a sablonokba.

Persze, ha a számokat megnézzük, néhány bájtról, esetleg néhány kilóbájtról beszélünk. Vajon számít ez mondjuk havi sávszélesség szintjén? Kliens vagy szerver oldali sebesség szintjén? A megrendelő gurujával való vitatkozásnál, aki szerint csak az a weboldal lehet jó, aminek minden egyes karakterét kézzel írta valaki Notepad-ben vi-ban?

Ti szoktatok erre figyelni?

 

Kitekintő: Symtorrent

Az egyetemi élet egyik nagy előnye, hogy az ember nem feltétlenül zárkózik be egy adott probléma- és technológiakörbe, hanem a különböző kompetencia területeknek köszönhetően technológiai sokféleség veszi körül. Van például nálunk egy kiváló mobilos csapat, nemzetközi eredményekkel.

A Kelényi Imre kollégám által fejlesztett Symtorrentet például 5 nap alatt több, mint ezren töltötték le. Íme egy kis ízelítő:

 

Technorati Tags: ,

Windows Live Messenger error 81000451

A kíváncsiság néha erősebb a józan észnél, ezért időnként hajlamos vagyok az éles gépemre béta szoftvereket telepíteni. Bár nem vagyok chatfüggő, feltettem az új Live Writer mellé a Live Messengert is, aminek meg is lett az eredménye, be sem tudok jelentkezni.

Pontosabban:

Signing in to Windows Live Messenger Beta failed because the service is temporarily unavailable. Please try again later. Error code: 81000451

Némi guglizás után rájöttem, hogy a csoportokhoz nem szabad, nem lett volna szabad hozzányúlni. A block és a leave funkciók, különösen üres csoportoknál okozzák a gondot. Egy darabig megoldást jelentett, hogy a Messenger indítása előtt töröltem az alábbi mappákat:

  • C:UsersfelhasználónévAppDataLocalMicrosoftMessenger
  • C:UsersfelhasználónévAppDataLocalMicrosoftWindows Live Contacts
  • C:UsersfelhasználónévAppDataRoamingMicrosoftMSN Messenger

Egy ideje azonban ez sem segít, nem sikerül a bejelentkezés, sőt sem frissíteni, sem eltávolítani nem sikerült sem a Messengert, sem a Writert.

Szerencsére ma megjelent az új (várhatóan utolsó) Windows Live Essentials béta verzió. A telepítő érdekessége, hogy már tartalmazza a Silverlight 2-t is, amit nem kötelező telepítenünk. További információk és letöltés itt: http://download.live.com/

Technorati Tags: ,,

Request filteringgel a gonosz ellen

Az MSDN Kompetencia Központ honlapján megszaporodtak az olyan rossz indulatú webes kérések, amit szemmel láthatóan robotok küldenek, próbálva felderíteni a webhely által használt technológiákat, hogy kihasználhassák azok sebezhetőségeit. Itt az ideje, hogy megszabaduljunk tőlük.

Az ilyen kérések többnyire olyan URL-re mutatnak, ami nálunk tipikusan nem is létezik. Például teljesen hiába jön kérés errors.php oldalra, olyanunk biztosan nincs. Az ilyen nem létező URL-eket természetesen az IIS elhajtja 404-es hibával, kicsit szemeteli a logot, de komoly gondot nem okoz.

Ami viszont gondot jelent, az a /Articles útvonal, ebben a névtérben ugyanis virtuális URL-eket kezelünk (mint ahogyan azt egyébként több más blog motor is teszi). Magyarul a http://www.msdnkk.hu/Articles/Csharp_programozas_allasinterju_kerdesek oldal úgy készül, hogy a bejövő kérést keresztül zavarjuk az ASP.NET motoron, átadjuk a kérést egy teljesen más címen elérhető oldalnak, amely az URL vége alapján adatbázisból  megjeleníti a cikket. Ennek a folyamatnak sajnos csak a legvégén derül ki, ha az URL-ben megadott cikk nem létezik.

Ráadásul a gonosz kis robotok szemmel láthatóan felismerik az ilyen címeket és éppúgy próbálkoznak, mint amikor Article.aspx?id=<guid> típusú címeink voltak. (Bár nagyságrendekkel visszaesett az ilyen próbálkozások száma.) Az utóbbi időben például rengeteg kérés jön a /Articles/xmlrpc.php címre, amit természetesen naplózunk, hogy tudjuk javítani a hibás linkjeinket. Legegyszerűbben úgy lehet ezektől megszabadulni, hogy az IIS-ben bekonfiguráljuk a request filtering szolgáltatást. A request filteringhez nincs GUI az IIS Managerben, aki ragaszkodik hozzá, töltse le az IIS Admin Packot. A vagányabbak írhatják rögtön a web.configba:

    <?xml version="1.0" encoding="UTF-8"?>
    <configuration>
        <system.webServer>
            <security>
                <requestFiltering>
                    <denyUrlSequences>
                        <add sequence="Articles/xmlrpc.php" />
                    </denyUrlSequences>
                </requestFiltering>
            </security>
        </system.webServer>
    </configuration>

A kérés el sem jut az ASP.NET motorig, a kliens pedig ezt kapja:

HTTP Error 404.5 – URL Sequence Denied

 

Érdekel valakit, hogy mit tud még az IIS 7, írjak róla?

Vista SP2 és Windows Server 2008 SP2 CPP

Készül a Vista és a Windows Server 2008 második javítócsomagja, a fejlesztés most érkezett a nyilvános béta fázishoz. Érdemes kicsit előretekinteni, hogy mire is számíthatunk.

Az első, amit érdemes megfigyelni, hogy egyetlen telepítő csomag lesz, amely Vistán és Windows Serveren is működni fog. Ez leginkább annak köszönhető, hogy a Windows Server 2008 magja megegyzik a Windows Vista SP1-gyel, azaz a Windows Server 2008 tartalmazza az SP1-t.

Szerintem részben ebből következik, hogy az új javítócsomag nem lesz kumulatív, azaz csak akkor fog futni, ha előtte már az SP1-t telepítettük. Ez elsőre elég szokatlan, fájdalmas szakítás a korábbi hagyományokkal, de csak Vistán lesz macera. Persze várhatóan meg fog jelenni a slipstreamelt telepítő is és szűz rendszereken azt fogjuk futtatni.

Cserébe sikerült elérniük, hogy a Windows Update-ről letöltődő változat mindössze 40-90 MB körül van (bővebben a számokról itt lehet olvasni).

Ebből persze már sejtjük, hogy túl sok újdonságra nem számíthatunk, ettől még nem válik a gépünk Windows Server 2008 R2-vé. Íme egy ízelítő az újdonságokból, kiemelések tőlem:

  • Kb. 10%-kal jobb energiagazdálkodás. Ez szerintem egyre fontosabb, nem csak a laptopok és a data centerek költségei miatt, hanem mert így talán néhány fával több marad az unokáinknak.
  • Hálózattal kapcsolatos javítások elsősorban Bluetooth és Wi-Fi terén. Na ez sem fog ártani…
  • Service pack clean-up tool: visszakapjuk a feleslegesen foglalt diszk területet (bár ilyen már most is van, lásd vsp1cln.exe)
  • Teljesítmény javítások: Windows Search 4.0 és végre talán a sidebar sem fogja folyamatosan pörgetni a processzort.
  • Hyper-V RTM: természetesen csak Serveren, Vistán továbbra is marad a Virtual PC.

Nektek melyik fontos, vagy mit hiányoltok?

A béta programmal (Customer Preview Program, CPP) és a telepítővel kapcsolatos információk és letöltések itt találhatóak.

Javaval települ a Silverlight, ez már a vég?

Épp Javat telepítek a böngészőbe és nem hiszek a szememnek: jön vele a Silverlight! Pontosabban telepíthetjük vele az MSN Toolbart, aminek pedig az az érdekessége, hogy teljesen Silverlight alapú, azaz amikor az MSN Toolbart telepítem, települ a Silverlight is.

Java Setup: MSN Toolbar

Az MSN Toolbar egész felhasználói felülete valójában XAML, a böngésző shell pedig kontrollként hosztolja a Silverlightot. Magyarul akár az MSN Toolbart, akár a JRE-t telepíti valaki a gépére, lesz a gépén Silverlight 2 is. Ez a tény valahogy kimaradt a press release-ből 🙂 Gondolom a Sun annyira nem rajongott az ötletért, ezért az ily módon települő Silverlightot csak az MSN Toolbar tudja használni, tehát ha kellene a böngésző plugin is, akkor a felhasználónak külön kell telepítenie a Silverlightot (ismét) 😦

Egyébként, csak hogy egy kicsit a jövőbe nézzünk, hamarosan az összes Live kliens alkalmazás is alapértelmezés szerint telepíteni fogja a Silverlight 2-t (persze out-out lesz). Scott novemberben még azt írta, hogy az interneten most minden negyedik gépen van Silverlight, de úgy látom nagyon dolgoznak rajta, hogy ez az arány jobb legyen 🙂

Technorati Tags: ,,,