Monthly Archives: January 2009

Microsoft Spanyolviasz béta

Először is a tény: a Microsoft bejelentette a Microsoft Tag béta változatát. A Microsoft tag egy kétdimenziós vonalkód, amelybe URL-t, vCard információkat, telefonszámot vagy tetszőleges szöveget tehetünk. Az elkészített vonalkódot a mobiltelefonunkra telepített célszoftverrel, a beépített kamera segítségével ismertethetjük fel. Csakhogy aki követi a vonalkód világot annak számára ez a leírás már 1994 óta ismert, úgy hívják: QR code.

Bár kétdimenziós vonalkódból számos létezik, amennyire én tudom, egyik sem terjedt el consumer szinten világszerte. Ami talán kiemelkedik a többi közül az a QR Code (Quick Response), amely Japánban hódít, szinte nincs már plakát vagy hirdetés nélküle:

 QR_Code_jp_ad QR_Code_mini_ad QR_Code_ch_ad QR_Code_TheSun

Persze vannak extrém felhasználók is, már ruhára, sőt sírkőre is lehet kérni:

QR Code_add_to_friends  QR_Code_jp_grave

A Microsoft is rájött, hogy ez jó dolog, néhány évvel ezelőtt elindította a QR kódra épülő Windows Live Barcode szolgáltatást. Ez úgy tűnik nyom nélkül megszűnt, sehol nem találom…

Megjelent viszont helyette a Microsoft Tag, amiben két nagy újdonság van:

Az egyik, hogy a vonalkód nem fekete-fehér négyzetekre, hanem színes háromszögekre épül. Ez nem tűnik nagy durranásnak, sőt megnövelheti a használat költségeit nyomtatott esetekben (nem elég a fekete-fehér nyomat), elméletileg lényegesen több információ tárolását teszi lehetővé:

Kód kapacitás

Az elvet egyébként a Microsoft Research dolgozta ki High Capacity Color Barcode (HCCB) néven.

A másik nagy újdonság, hogy a vonalkódban csak egy egyedi azonosító tárolódik, amit a felismerő szoftver elküld a Microsoft internetes szolgáltatásának, ami az azonosító alapján adja vissza a kód jelentését. Ennek persze a felhasználó számára óriási hátránya, hogy a rendszer csak online módon működik – aminek a mobil szolgáltatók persze örülni fognak. A kód tulajdonosa számára viszont óriási lehetőség, hogy egy szerveren fut keresztül a felismerés, ugyanis lehet mérni a forgalmat (még location információkat is képes küldeni a kliens) vagy akár egy idő után le is járhat (expire) egy kód. A Nagy Testvér tehát figyel…

Az, hogy a kódban csak egy azonosító van, elméletileg lehetővé teszi hosszabb információk publikálását, nem beszélve arról, hogy a vonalkód fizikai mérete igen kicsi marad.

A ráadás pedig, hogy a Microsoft kilépett a saját világából és a felismerő szoftvert Windows Mobile mellett elkészítette Android, Blackberry, J2ME, PalmOS, Symbian, sőt még iPhone platformra is. Az alkalmazások a http://gettag.mobi oldalról tölthetőek le, itt akár ki is lehet próbálni őket:

Microsoft Tag: www.msdnkk.hu

Mivel a szolgáltatás ingyenes, azt hiszem minden adott a technológia elterjedéséhez. Az más kérdés, hogy vajon mennyivel járt volna rosszabbul a világ, ha a Microsoft a QR kód pályára áll rá és nem valami teljesen egyedivel áll elő…

Technorati Tags: ,,

Advertisements

Keresőbarát URL-ek IIS 7 alatt

Korábban már írtam az IIS 7-ben található request filtering komponensről, amely segítségével a bejövő URL-eket lehet szétszabdalni és bizonyos szempontok szerint engedélyezni vagy tiltani a kérés feldolgozását. Van egy másik eset, amikor a bejövő URL-t kell felparszolni, ez pedig virtuális URL-ek használatakor fordul elő. Vagyis amikor article.aspx?id=123 helyett barátságosabb, például article/123 formátumú címet szeretnénk használni. Erre szolgál az IIS 7-hez letölthető URL Rewrite Module komponens is.

A funkció egyébként nem új, az Apache mod_rewrite komponense már régóta tudja, de IIS alatt eddig csak fizetős komponenssel vagy egy kis ASP.NET programozással lehetett ezt a feladatot megoldani. ASP.NET-ben írtuk meg egyébként a korábbi devPortal és az MSDN Kompetencia Központ adatbázis alapú virtuális URL mappingjét is…

Szerencsére most már mindez megy kódolás nélkül is, csak le kell hozzá tölteni az ingyenes kiegészítést, ami valószínűleg az SP2-től már az IIS 7 része lesz. Az URL Rewrite modul segítségével a bejövő kérésnek gyakorlatilag bármely részére megfogalmazhatunk illeszkedési feltételt: az URL-re, a HTTP fejléc mezőkre, a query stringre vagy akár szerver változókra. Az illeszkedési feltételt megadhatjuk egyszerű wildcardos vagy reguláis kifejezés formájában. Ha a modulnak sikerül az általunk megadott szabályt ráillesztenie egy bejövő kérésre, a szabályban megadott címre irányítja át a kérést.

A dologban nem csak az a szép, hogy minden beállításunk a web.configban együtt utazik az alkalmazással, hanem az is, hogy az IIS Managerben a modulhoz tartozó grafikus felületen számos segítséget kapunk a szabályok szerkesztéséhez. Például sablonok és tesztelési felület is rendelkezésre áll.

Például valószínűleg sokan írtunk már le valami hasonlót:

    <asp:HyperLink runat="server" 
Text='<%# Eval("Title") %>' NavigateUrl='<%# Eval("ID", "Article.aspx?id={0}") %>' />

Sokkal szebb lenne, ha ezt írnánk:

    <asp:HyperLink runat="server" 
Text='<%# Eval("Title") %>' NavigateUrl='<%# Eval("ID", "Article/{0}") %>' />

Ahhoz, hogy ez működjön, persze kell egy kicsit varázsolni az IIS Managerben. Az URL Rewrite modulban kattintsunk az Add Rules… gombra, majd válasszuk a User friendly URL sablont: URL Rewrite: új szabály létrehozása

Adjuk meg azt az URL-t, amivel most működik az alkalmazásunk és válasszuk ki azt, ahogy a felhasználóknak láttatni szeretnénk a címet. Itt érdemes arra figyelni, hogy bár címként a szerver nevét is meg kell adni, az illesztési mintában és az átírt címben erre nincs szükség. Szintén érdemes kihagyni az alkalmazásunk virtuális mappáját.

URL Rewrite: új szabály létrehozása varázslóval

Ha az alsó Create corresponding redirect rule jelölőnégyzetet bekattintjuk, akkor a nem kívánatos query stringes címről is át lesznek irányítva a kérések a barátságos címre.

A varázsló leokézása után a megjelenő új szabályra duplán kattintva módosíthatjuk azt:

URL Rewrite: szabály szerkesztéseJó tudni, hogy itt válthatunk át reguláris kifejezésekről egyszerű wildcardos keresésre, illetve itt található a Test pattern funkció is, ahol kipróbálhatjuk, hogy a mintánk jól működik-e az általunk megadott URL-re.

A sok kattintgatás eredménye a web.configban található:

    <system.webServer>
        <rewrite>
            <rules>
                <clear />
                <rule name="RewriteUserFriendlyURL1" stopProcessing="true">
                    <match url="^article/([^/]+)/?$" />
                    <conditions>
                        <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
                        <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
                    </conditions>
                    <action type="Rewrite" url="article.aspx?id={R:1}" />
                </rule>
            </rules>
        </rewrite>
    </system.webServer>

Ennyi az egész, máris működik! Persze csak akkor, ha mindent jól csináltunk. Ha nem, akkor 404 – Not Found hibaüzenetet fogunk kapni. Akkor nincs más hátra, elő kell kapnunk az IIS 7 Failed Request Tracing szolgáltatását és meg kell néznünk, hogy az URL Rewrite modul működik-e vagy sem. Vegyünk fel egy új tracing szabályt a 404-es hibakódra és a trace providerek közül válasszuk ki a Rewrite komponents:

URL Rewrite: failed request tracing

Kérjük le az oldalt, majd nézzük meg a logot a C:inetpublogsFailedReqLogFilesW3SVC1 mappában:

URL Rewrite: failed request tracing log

A PATTERN_MATCH és RULE_EVALUATION_END szekciókban figyeljük a Matched és a Succeeded értékeket. Ha false, akkor bizony valamit nem jól csináltunk. Én így jöttem rá, hogy az alkalmazás mappájának nevére (a fenti képen UrlRewriteSample) nincs szükség…

Ez persze csak egy alkalmazása az URL Rewrite modulnak…

A cikkhez tartozó példa kód letölthető innen.

 

Az IIS log kigazolása

Jól működő weboldal esetén az ember ritkán nézi a webszerver naplóját, hiszen a durva hibák úgyis megjelennek a Windows eseménynaplójában, a forgalmi statisztikákat pedig a Google Analytics adja közvetlenül. Ha viszont mégis bele kell kukkantani, jön az elszörnyedés, mi ez a sok szemét és hova bújt a lényeg? Íme néhány tipp a webkiszolgáló naplójának tisztán tartásához.

Aranyszabály: amire soha nem leszünk kíváncsiak, azt ne naplózzuk!

A gyakorlatban ez általában azt jelenti, hogy nem érdekelnek a .jpg, .gif., .png, .js és .css fájlokra érkező HTTP kérések. Érdekelnek a letöltések, az oldal lekérések, hogy a böngészők megtalálták-e a favicon.ico fájlunkat, de képek, szkriptek és stíluslapok lekérését még soha nem akartam visszakeresni. Egy fotóblog vagy galéria oldalnál biztosan akarnám, olyanom viszont nincs.

A naplózást IIS6-ban ki lehet kapcsolni a Log visits kapcsolóval a webkiszolgáló minden szintjén, a beállítás öröklődik lefelé:

IIS 6: Log visits

IIS 7 esetén azonban a grafikus felületen nem fogunk ilyen nevű kapcsolót találni. Sőt, amikor először megnézzük egy mappa vagy webhely Logging beállításait minden vezérlő kikapcsolt állapotban lesz, a lényeg azonban ott virít jobb oldalon:

IIS 7: Disable logging

Ha itt kikapcsoljuk a loggolást, ez fog beíródni az applicationHost.config fájlba:

    <location path="Default Web Site/images">
        <system.webServer>
            <httpLogging dontLog="true" />
        </system.webServer>
    </location>

Látható, hogy a lényeg a httpLogging elem, a célra tartást pedig a location elemmel végezhetjük el. Ha már ezt tudjuk, takarítsuk el az ASP.NET .axd handlereit a logból. Írjuk például ezt a saját alkalmazásunk gyökér web.configjába:

    <?xml version="1.0" encoding="utf-8"?>
    <configuration>

        <!-- Szokásos részek... -->

        <location path="ScriptResource.axd">
            <system.webServer>
                <httpLogging dontLog="true" />
            </system.webServer>
        </location>
        
        <location path="WebResource.axd">
            <system.webServer>
                <httpLogging dontLog="true" />
            </system.webServer>
        </location>
    </configuration>

Megsúgom, ebből baj lesz. Mégpedig azért, mert a httpLogging szekció alapértelmezés szerint nincs delegálva, tehát csak az applicationHost.config fájlban szerkeszthető. A jutalmunk egy szép HTTP Error 500.19:

The requested page cannot be accessed because the related configuration data for the page is invalid.

This configuration section cannot be used at this path. This happens when the section is locked at a parent level. Locking is either by default (overrideModeDefault="Deny"), or set explicitly by a location tag with overrideMode="Deny" or the legacy allowOverride="false".

Ha hasonlóan a képek naplózását tiltjuk le, azt fogjuk tapasztalni, hogy az oldalaink betöltődnek, csak éppen a képek fognak hiányozni róluk.

Ha jól végiggondoltuk, hogy ezt a lehetőséget inkább a webhely gazdájának kezébe adnánk, irány a Feature Delegation az IIS Managerben, billentsük át a Logging sort Read/Write-ra:

IIS 7: Logging feature delegation

Ettől kezdve location tag nélkül is tehetünk web.config fájlokat például a css vagy images mappáinkba.

Sajnos a location nem ismerni a wildcardokat, nem tudjuk tehát egyszerűen kizárni a webhelyünkhöz tartozó összes .jpg fájlt. Ezért érdemes úgy szervezni a fájljainkat, hogy a naplózásból tiltandó fájlok egy mappában vagy annak almappáiban legyenek.

Az IIS 7-ben megtehetjük azt is, hogy csak a sikertelen kéréseket naplóztatjuk, azaz ahol a HTTP status code 400 vagy nagyobb. Ehhez a httpLogging szekcióban használjuk a selectiveLogging=”LogError” attribútumot.

 

Hány kötelező attribútuma van egy ASP.NET vezérlőnek?

A Visual Studio szerint kettő. Szerintem egy.

Ha néhány héttel ezelőtt megnézte valaki az MSDN Kompetencia Központ honlapján a cimkefelhő HTML kódját, valami ilyesmit láthatott volna:

    <div class="tagContent">
            <span id="ctl00_cphMain_TagCloud1_dtlTagCloud">
                    <span>
                            <a id="ctl00_cphMain_TagCloud1_dtlTagCloud_ctl00_hypTag" 
                               class="Tag1" rel="tag" href="Tags/.NET">.NET</a>
                    </span>
                    <span>&middot;</span>
                    <span>
                            <a id="ctl00_cphMain_TagCloud1_dtlTagCloud_ctl02_hypTag" 
                               class="Tag3" rel="tag" href="Tags/Active%20Directory">Active Directory</a>
                    </span>
                    <span>&middot;</span>
                    <span>
                            <a id="ctl00_cphMain_TagCloud1_dtlTagCloud_ctl04_hypTag" 
                               class="Tag3" rel="tag" href="Tags/ASP.NET">ASP.NET</a>
                    </span>
                    <span>&middot;</span>
    <!-- stb. -->

Ez bizony némi javításért kiált! Sok benne a felesleges span és sok benne a felesleges id.

A spanektől egyszerű volt megszabadulni: a listát korábban egy DataList vezérlő állította elő adatkötéssel, ez viszont köztudottan telespaneteli a kimenetet. Átírtuk ListViewra és tada, megszűnt ez a probléma.

A másik érdekesség a gusztustalanul sok és hosszú ID. Ezektől sem nehéz megválni: ne adjunk a szerver oldali vezérlőnek ID attribútumot! Nem kell neki! Gondoljuk csak végig, hogy miért van az ID? Hogy azonosítani tudjuk a vezérlőt, amikor code behindból hivatkozunk rá. Ha nincs code behind, nem kell az ID!

Kérdés persze, hogy okoz-e az ASP.NET-nek gondot, ha nincs ID? Ehhez csak meg kell keresnünk Reflectorban a System.Web.UI.WebControls.WebControl osztály AddAttributesToRender metódusát, ez felelős ugyanis ennek az attribútumnak a HTML markupba generálásáért:

    protected virtual void AddAttributesToRender( HtmlTextWriter writer )
    {
        if( this.ID != null )
        {
            writer.AddAttribute( HtmlTextWriterAttribute.Id, this.ClientID );
        }

        //...
    }

Látható, hogy nem repül kivétel, ha a this.ID null, csak éppen nem történik semmi.

Amikor Visual Studioban behúzok egy vezérlőt a Toolboxról, a nagyokos azt hiszi, hogy majd biztosan programozni szeretném, ezért ad neki rögtön ID és runat=”server” attribútumokat. Ebből egyedül a runat=”server” kell, az ID nem! Sajnos a webfejlesztő dolga, felelőssége, kötelessége, hogy a felesleget törölje a markupból.

Az ID törlése után ez maradt a cimkefelhőnkből:

    <div class="tagContent">
        <a class="Tag1" rel="tag" href="Tags/.NET">.NET</a> 
        &middot; 
        <a class="Tag3" rel="tag" href="Tags/Active%20Directory">Active Directory</a> 
        &middot; 
        <a class="Tag3" rel="tag" href="Tags/ASP.NET">ASP.NET</a>
        &middot;
    <!-- stb. -->    

Miután töröltük a felesleges HTML tageket és attribútumokat, a cimkefelhő HTML markupja a harmadára csökkent.

Szerintetek érdemes erre figyelni, fontos ez?

 

Technorati Tags: ,