Monthly Archives: December 2008

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: ,,,

Az Excel 2007 adatbányászati bővítményeinek használata – screencast

Az Excel 2007-hez ingyenesen letölthető Data Mining Add-ins for Microsoft Office 2007 nevű kiegészítés segítségével a felhasználók az SQL Server Analysis Services mélyebb ismerete nélkül, varázslók támogatásával, a megszokott Excel környezetben oldhatnak meg adatbányászati feladatokat.

Első lépések

A bővítmény valójában két Excel és egy Visio kiegészítést tartalmaz. A Data Mining Client for Excel a szalagon jeleníti meg a Data Mining fület, melyen a Business Intelligence Development Studiohoz hasonló műveleteket végezhetünk el. Bár szinte minden gomb egy-egy varázslót indít el, ezek használatához célszerű ismerni az adatbányászat fogalmait.

A bővítmény másik komponense a jóval egyszerűbb Table Analysis Tools, amely az Excel tábla objektumait okosítja fel. A telepítés után, ha bármelyik táblára kattintunk, megjelenik a Table Tools csoportban egy Analyze fül és a hozzá tartozó szalagon számos adatbányászati funkció.

Jó tudni

Bármelyik szalag funkcióit használjuk, ne felejtsük el, hogy a háttérben szükség van az SQL Server Analysis Servicesre és azon belül egy adatbázisra, melyben a felhasználónak jogosultnak kell lennie objektumok létrehozására. A szükséges kiszolgáló paraméterek beállítását és munka adatbázis létrehozását a bővítmény telepítő könyvtárában található Microsoft.SqlServer.DataMining.Office.ServerConfiguration.exe alkalmazás segítségével tudjuk könnyen elvégezni.

Demó

A demóban bemutatjuk, hogyan használhatóak az Excel 2007 adatbányászati bővítményei kampányelemzési feladatok megoldására. A videó a képre kattintva megtekinthető böngészőben vagy a kép alatti linkre kattintva letölthető:

Az Excel 2007 adatbányászati bővítményeinek használata - screencast

Letöltés: Excel_2007_adatbanyaszati_bovitmenyeinek_hasznalata_(Balassy_Gyorgy).wmv (25:29, 152 976 KB)

További információk

 

Unknown error 0x80072f78

Az eszem megáll, hogy 2008-ban még mindig vannak ilyen hibaüzenetek! Semmi leírás, csak egy HRESULT, aztán kezdj vele, amit akarsz. Ez éppen Windows Mobile 6.1-en jött elő, amikor megpróbáltam Pocket Internet Explorerből az ActiveSync desktop pass-through kapcsolatán keresztül elérni az internetet.

The page you are looking for cannot be found due to unknown error 0x80072f78.

A hiba a Layered Service Provider (LSP) környékén van, egy kis nem támogatott registry buherálással meg lehet oldani, csak ennyit kell bemásolni egy .reg fájlba és futtatni a PC-n:

    Windows Registry Editor Version 5.00

    [HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows CE Services]
    "AllowLSP"=dword:00000000

A .reg fájl letölthető innen.

 

Dátum formátum állítás Windows Mobile-on

Frissítettem a telefonom operációs rendszerét, és bár nem hivatalos és támogatott ROM verzióval, de végre sikerült átállnom Windows Mobile 6.1-re. Az angol operációs rendszeren az egyik első utam a Regional Settings ablakba vezetett, mert megpróbáltam átállítani a dátumok megjelenítését a magyar formátumra. Nem ment könnyen…

Egy tappintással kiválasztottam a Hungarian területi beállításokat, szépen meg is jelent példaként a magyar szám- és dátum formátum. A Today Screenen azonban nem így jelent meg a dátum, akárhogy is frissítettem vagy indítottam újra a telefont. Szemmel láthatóan a long date format beállítás mintha nem íródna be a registry-be a Regional Settings módosítása után.

Így nem maradt más hátra, közvetlenül firkáltam át a telefonon a registry-t, itt:

HKEY_LOCAL_MACHINEnlsoverrides

SLDte = yyyy. MMMM d. dddd

Aki nem szokott ilyen formázásokhoz, annak tudom ajánlani az MSDN Custom Date and Time Format Strings oldalát vagy Kathy Kam .NET Format String 102: DateTime Format String című blog bejegyzését.

Elsőre persze elbizonytalanodtam, hogy ha ilyen alapvető gondok vannak, akkor nagyobbak is lehetnek (még egyszer megjegyzem, nem hivatalos ROM verzióról van szó, a Mio A701-hez ugyanis a gyártó nem adott ki), de összességében megérte a frissítés. A rendszer sokkal kezelhetőbb és bizony vannak olyan új funkciók, amelyek már nagyon hiányoztak, például végre tudok magyar ékezetes nevekre keresni a telefonkönyvben! Igen, az ember egy idő után már ilyen apróságoknak is tud örülni… 😉