Monthly Archives: March 2007

Win the Web ’07 – Fedezd fel a tehetséged

Számtalanszor keresnek meg cégek azzal, hogy tudok-e olyan tehetséges fiatalt közvetíteni nekik, aki mostanában készül befejezni az egyetemet vagy aki a diplomatervezést az adott cégnél végezhetné. A feladat számos ok miatt nem egyszerű és bár a Microsoft Gyakornoki Program segít egy kicsit, az MSDN Kompetencia Központban úgy határoztunk, hogy megpróbáljuk közvetlenül összekapcsolni a tehetséges, lelkes ifjúságot és az ipari projekteken dolgozó cégeket.

Így született meg a Win the Web ’07 – Fedezd fel a tehetséged webfejlesztői- és tehetségkutató verseny ötlete. A hasonló versenyekhez képest a nagy eltérés, hogy nem csak egyetemi csapatok küzdenek egymással, hanem gyakorlatilag bármilyen csapat nevezését elfogadjuk, sőt bátorítjuk a cégeket, a professzionális webfejlesztő cégeket, hogy ők is indítsanak csapatokat és vegyenek részt a versenyen.

A profi webfejlesztő cégeknek ez nyilván reklám lehetőség, hiszen megmutathatják, hogy az ő csapatuk a legjobb és ezzel esetleg projektekhez juthatnak, de emellett talán még fontosabb, hogy közvetlenül és személyesen találhatják meg azokat az ifjú titánokat, akikkel bővíthetik csapatukat. 

Diákoknak szintén lehetőség, nem csak az 1 millió forintos fődíj miatt, hanem mert elbeszélgethetnek azokkal, akik a webfejlesztés területén számottevően jelen vannak a magyar piacon, továbbá a fődíjak között közvetlen állásajánlatok is szerepelnek!

Ha tehát úgy érzed, hogy indulnál a versenyen, nincs más dolgod, mint szerezni magad mellé még két embert és regisztrálni a csapatot az alábbi címen, ahol bővebb információkat is olvashatsz a versenyről:

http://www.msportal.hu/WinTheWeb

Találkozunk május 12-én!

Kliens oldali adatkötés

Úgy tűnik, hogy a Microsoft AJAX Library fejlesztői nem szimplán a konkurenciát akarták lenyomni, hanem tényleg azt tartották szem előtt, hogy egy JavaScript osztálykönyvtárban milyen funkciókra van szükség. Van például benne kliens oldali adatkötés! Persze felmerül a kérdés, hogy szép, de mire jó? 

Miután aszinkron módon megszereztünk adatokat a szervertől, azokat valahogy meg is kéne jeleníteni. Erre a hagyományosan kétféle megközelítés képzelhető el:

  1. A szerver szépen megformázza az adatokat, eleve HTML fragmentet küld a kliensnek, amely azt az innerHTML tulajdonság segítségével egyszerűen megjeleníti.
  2. A kliens végigiterál a valamilyen formában (XML, JSON) leküldött adatokon és sztring vagy DOM buherálással létrehozza az új felhasználói felület elemeket (DIV-eket, SPAN-eket, listákat, táblázatokat)

Ehhez jön most a harmadik lehetőség: egyszerűen kössük hozzá a szerver által küldött adatokat kliens oldali felhasználói felület elemekhez. A szervernek így nem kell formáznia, a kliensre pedig nem kell kódot írnunk, a szükséges buherálást az adatkötés mögöt rejtőző AJAX Library fogja elvégezni (mert valakinek mégis csak meg kell tennie).

Első lépésként szükségünk lesz valamilyen adatforrásra. Az adatok jöhetnek a szerverről is, de hogy egyszerűbb legyen a példa, egy objektum tömböt fogunk használni, amit JSON-ból inicializálunk:

    var result = 
    [
      { Name: "Balássy György", Url: "http://balassy.spaces.live.com", ImageId: "0959d967-329e-49bb-903f-6ca5a9c88e52" },
      { Name: "Gincsai Gábor", Url: "http://www.aut.bme.hu/portal/gincsai", ImageId: "43a1bf97-0b07-4a41-a563-b34dc3f3d2d7" },
      { Name: "Dávid Zoltán", Url: "http://www.aut.bme.hu/portal/dzoli", ImageId: "04b3c904-6323-4c1c-a729-01ff5b543351" },
      { Name: "Kereskényi Róbert", Url: "http://www.aut.bme.hu/portal/roby", ImageId: "408778ae-1749-4252-a04d-5c416acaf0a7" },                                        
      { Name: "Virág András", Url: "http://www.aut.bme.hu/portal/viragand", ImageId: "" }
    ];

Minden objektumnak van Name, Url és ImageId tulajdonsága, amit kötnünk kell.

A szerver oldali kötéshez hasonlóan itt is meg kell adnunk template-eket, azonban itt a template és a kötés nem együtt, hanem az oldal különböző részein találhatóak. Listát szeretnék létrehozni, ehhez a következő template megfelelő lesz:

    <div id="output"></div>
    
    <div style="display: none;">
        <div id="listLayout">
<h1>MSDN Kompetencia Központ Portál Technológiák Csoport</h1> <ul id="itemParent"> <li id="item">
<img id="photo" style="height:50px;width:40px;" />
<a id="name"></a>
</
li> </ul>
<a href="http://www.devportal.hu/Portal/Webdevelopment.aspx"> devPORTAL Webfejlesztés témaközpont </a> </div> </div>

Az output azonosítójú taget fogjuk arra felhasználni, hogy ott megjelenítsük a listánkat, a második DIV pedig maga a template, amit a kötéshez fogunk felhasználni. Itt is el kell látni néhány elemet tetszőleges id-val, hogy a kötésnél hivatkozni tudjunk rájuk:

  • listLayout: Ez lesz az egész listánk sablonja, ezen belül tudunk megadni például fejlécet és láblécet.
  • itemParent: Ez lesz az egyes rekordjainkat tartalmazó konténer, tehát ami ezen belül van, az elemenként ismétlődik, ami pedig ezen kívül van, az fejléc vagy lábléc.
  • item: Az egyes rekordok adatait összefogó elem.
  • photo, name: Az adatkötésnél így fogunk hivatkozni a rekordonként megjelenő IMG és A tag-ekre.

Az adatkötést XML Scriptben írjuk le, mert sokkal átláthatóbb, mint soronként beállítani minden tulajdonságot:

  <script type="text/xml-script">
    <page xmlns="http://schemas.microsoft.com/xml-script/2005">
      <components>
        <listView itemTemplateParentElementId="itemParent" id="output">
          <layoutTemplate>
            <template layoutElement="listLayout" />
          </layoutTemplate>

          <itemTemplate>
            <template layoutElement="item">
              <hyperlink id="name">
                <bindings>
                  <binding dataPath="Name" property="text" />
                  <binding dataPath="Url" property="navigateURL" />
                </bindings>
              </hyperlink>
              <image id="photo">
                <bindings>
                  <binding dataPath="ImageId" property="imageURL" 
                    transform="ToString" 
                    transformerArgument="http://www.aut.bme.hu/Portal/Default/DesktopModules/PictureResolver.aspx?PictureId={0}&amp;CultureId=16df90ec-fcf2-466d-8f3e-8c4057561621" />
                  <binding dataPath="Name" property="alternateText" />
                </bindings>
              </image>
            </template>
          </itemTemplate>
        </listView>
      </components>
    </page>
  </script>

 Kis segítség az XML megértéséhez:

  • Az adatkötéshez a Sys.Preview.UI.Data.ListView kontrollt használjuk, ami a PreviewScript.js fájlban található.
  • A ListViewban az egyes elemek sablonját (hasonlóan a szerver oldali kötéshez) egy item template segítségével írjuk le.
  • Az itemen belül lévő A tag-et egy Sys.Preview.UI.HyperLink (<hyperlink>), az IMG tag-et pedig egy Sys.Preview.UI.Image (<image>) kontroll segítségével kötjük. A linknek text és navigateURL tulajdonsága van, a képnek imageURL és alternateText.
  • Az adatkötés WPF jellegű, a következő tulajdonságokat lehet beállítani:
    • dataContext: az adatforrás objektum neve. Itt nem szerepel, mert ezt kódból fogjuk megadni.
    • dataPath: az adatforrás forrás tulajdonsága ("ezt kötjük…").
    • property: a cél vezérlő elem cél tulajdonsága ("… ehhez").
    • transformer: transzformációt végezhetünk az adatokon, mielőtt megérkeznének a cél tulajdonsághoz. A ToString transzformer lényegében egy String.Format művelet, amelynek szüksége van egy {0} placeholderre.
    • transformerArgument: a megadott transzformációhoz szükséges paramétereket tudjuk átadni. Példánkban azt a mintát, amelyben egy {0} placeholder helyére kerül be az adat.

Nem marad más hátra, mint a result változóban lévő adatokat a kontrollhoz kötni a data tulajdonságon keresztül:

    $get( 'output' ).control.set_data( result );

Persze ezt is megtehetjük deklaratívan a Sys.Preview.Data.DataSource osztály segítségével, ám ez leginkább akkor hasznos, ha szerver oldali webszolgáltatást akarunk hívni.

Van tehát egy deklaratív, tisztán kliens oldalon futó adatkötésünk, ami lényegesen átláthatóbb és karbantarthatóbb, mint az egymásba ágyazott for-ciklusok. Sőt, az eredményt lehet kliens oldalon rendezni is, de erről majd legközelebb… smile_wink

 

Technorati tags: , ,

Tipp: érdekes AJAXos hibák

Előfordulhat, hogy egy AJAX-os webalkalmazás mozgatásakor vagy telepítésekor a következő web.configra utaló hibaüzenetet kapjuk:

Configuration error: Unrecognized configuration section ‘system.webServer’

vagy:

Configuration error: Unrecognized attribute ‘type’.

Ha teljesen biztosak vagyunk abban, hogy minden szükséges komponenst feltelepítettünk (AJAX Extensions, Futures CTP stb), akkor érdemes ellenőrizni az IIS-ben az adott virtuális mappa beállításai között, hogy melyik ASP.NET verziót használjuk. Az AJAX csak az ASP.NET 2.0-val működik!

 

Technorati tags: ,

Verziókezelés Microsoft módra: ASP.NET AJAX harmadszor

Úgy látszik kezd kivattá válni a Microsoftnál, hogy csendben adják ki fejlesztőeszközök új verzióit. Március elején az SQL Server SP2 jelent meg kétszer, most pedig az ASP.NET AJAX Extensions 1.0 változata érte meg a harmadik kiadást. Úgy emlékszem, hogy először január 29-én jelent meg, aztán január 31-én, most pedig azt látom, hogy a letöltő oldalon a dátum 2007. március 2., de semmi bővebb információt nem találtam a változásokról, pedig a fájlok között méretkülönbség nem elenyésző. A hivatalos verzió tehát továbbra is 1.0. smile_confused

 

Technorati tags: ,

Szerszámosláda AJAX fejlesztőknek

Mivel az utóbbi hetekben rengeteg időt sikerült AJAX fejlesztéssel eltöltenem, elkerülhetetlenné vált, hogy felszerelkezzem néhány eszközzel, melyek nélkül a kliens oldali AJAX fejlesztés elég keserves lenne. Nézzük mik segíthetik egy AJAX fejlesztő életét:

1. ASP.NET AJAX dokumentáció

Nesze semmi fogd meg jól Microsoft módra: dokumentáció éppenséggel van, sőt Scott szerint márciusban egészen sokat frissült, de még mindig szinte használhatatlan. Konkrétan a kliens oldali osztályok esetén csak az 1.0 RTM verzió fájljait tartalmazza, a Futures CTP-be került osztályokról egy kukkot sem ír. Ez lényegében azt jelenti, hogy még egy TextBox tulajdonságai sem derülnek ki belőle. Az alap osztályoknál mégis segít eligazodni, sőt még néhány példát is találunk benne. Nagyon kellene belőle egy kereshető, mondjuk MSDN-hez hasonló CHM formátum, mert a mostani állapotában IIS alá kell webalkalmazásként felmásolni.

Online változat | Letöltés

2. Eilon Lipton: ASP.NET AJAX JavaScript Class Browser

Reflector JavaScript fájlokra, így mindenki érti, miről van szó. Érdemes a legújabb verziót (most épp take 3) letölteni, és a leírás szerint hozzávenni a Preview osztály fájljait és máris egyszerűbb eligazodni a CTP-ben. Sajnos találtam már olyan tagot, amit nem mutatott meg egy osztálynál, de az esetek maradék 99.9%-ban jó hasznát vettem. Kicsit reszeltem a CSS-en, hogy barátságosabb legyen olvasni. Nagyon hiányzik belőle, hogy a metódusok esetén az Object pontosan micsoda (például Control vagy DomElement), mégis nagy segítség. Sajnos ő sem CHM, ami azért bocsátható meg, mert az élő JavaScript fájlokat fejti vissza, cserébe viszont a hivatalos AJAX doksikhoz hasonlóan őt is IIS alá kell másolnunk webalkalmazásként.

Leírás | Közvetlen letöltés

3. Milan Negovan: AJAX Library Cheat Sheets

Aki szereti a fali plakátokat, annak ideális lehet ez a néhány egy-egy oldalas PDF-ből álló gyűjtemény, amely az AJAX Library legfontosabb osztályait mutatja be. Nagy előnye, hogy vannak benne példák is, illetve rövid kigyűjtések, legjobban a dátumformátumok illetve az esemény paraméter tulajdonságok táblázatának vettem hasznát. Sajnos még elég rövidke, de Milan ígérete szerint fogja még bővíteni a létszámot.

Leírás | Közvetlen letöltés

4. Internet Explorer Developer Toolbar

Ezt a böngésző bővítményt remélem nem kell bemutatnom, webes fejlesztésnél szinte nélkülözhetetlen. Azon kívül, hogy CSS tulajdonságok lekérdezésére ideális, AJAX fejlesztésnél nagyon jól be lehet járni vele a dinamikusan felépített DOM objektumokat, például egy adatkötésnél.

Egy ismertető cikk | Letöltés

5. Nikhil Kothari: Web Development Helper

Másik jól használható böngésző bővítmény, amelynek legnagyobb használt loggoláskor vettem. Képes mind a HTTP forgalmat, mind pedig a trace kimenetet naplózni. Ha tehát használjuk a Sys.Debug osztályt, akkor a trace metódusok kimenetei már nem csak TEXTAREA-ban vagy a Visual Studioban tudnak megjelenni, hanem közvetlenül a böngészőben is, anélkül, hogy debug módban futtatnák a szkriptjeinket.

Leírás | Közvetlen letöltés (0.8.3.0): telepítő és dokumentáció

6. Cyril Durand: XML-Script IntelliSense XSD

A Microsofttól hivatalosan majd csak a Visual Studio Orcas változatával kapunk IntelliSense-t a kliens oldali fejlesztéshez, ami leginkább XML Script írása közben hiányzik nagyon. Cyril megalkotott egy XSD fájlt, amit bedobva a C:Program FilesMicrosoft Visual Studio 8XmlSchemas mappába máris jön a segítség, ha az XML Scriptet külső fájlban szerkesztjük. Mutat egy szkriptet arra is, hogy a külső fájlban lévő XML Scriptet hogyan lehet futási időben betölteni az oldalra, de tapasztalataim szerint ez nem tökéletes, a sokadik mélységben lévő XML tag már nem kerül feldolgozásra.

Leírás | Közvetlen letöltés

7. MSDN Kompetencia Központ: AJAX Library Project Template

Ez a mi ráadásunk lesz a szombati Web Konferenciára, addig meglepetés present

 

Technorati tags: , ,

Hibakeresés és nyomkövetés JavaScriptben

Szerver oldali programozók számára a JavaScript írásnál csak egy rémisztőbb és utálatosabb dolog létezik: JavaScriptet debuggolni. Márpedig ha elkezdjük használni a Microsoft AJAX Library-t akár önállóan, akár az ASP.NET AJAX részeként, előbb utóbb erre is szükségünk lesz.

Debug környezet kialakítása

Ahhoz, hogy minden kézre álljon, először az Internet Explorert kell beizgatnunk a hibakeresére, irány tehát a Tools – Internet Options – Advanced fül és ott:

  • Disable script debugging (Internet Explorer): off
  • Disable script debugging (Other): off
  • Display a notification about every script error: on
  • Show friendly HTTP error messages: off

Ha szerver oldali kóddal együtt használjuk az AJAX Library-t, akkor állítsuk be web.config-ban a debug="true" kapcsolót, így a kliens oldali szkriptek debug változatával fog futni az oldalunk, ami segíthet a hibakeresésben.

De nincs feltétlenül szükségünk az ASP.NET-re, lehet debuggolni egyszerű HTML oldalba ágyazott szkriptet is. Ebben az esetben is érdemes lehet Visual Studioban létrehozni egy webes projektet, már csak azért is, mert:

  • Megkapjuk a Studio szokásos kód szerkesztési szolgáltatásait.
  • Könnyebb lesz a böngészőt és a Studio debuggerét összekapcsolni.
  • Használhatjuk a Studio részeként elérhető developer web servert.
Debug

A Microsoft AJAX Library hibakeresési szolgáltatásait a Sys.Debug osztály fogja össze. Ha bárhol a forráskódban meghívjuk a fail metódust, a böngésző meg fogja kérdezni, hogy akarunk-e debuggolni, és ha igen, akkor rögtön rá tud csatlakozni a VS-ben megnyitott webes projektünkre. Ennyi a forráskódban:

    Sys.Debug.fail( "Irány a debugger!" );

Ennyi a böngészőben:

A Yes-re kattintva az élmény ismerős lesz, csak tegyünk F9-cel egy breakpointot a következő szkript sorra és máris mehetünk végig soronként az F10-et csapkodva. Ha az AJAX Library szkriptek debug változatait linkeljük be az oldalunkra, akkor F11-gyel is érdemes lehet ugrálni, megnézhetjük, mit hogyan implementált a Nagy Testvér! Ki lehet például deríteni, hogy a fail a böngésző debugger utasítását használja, amennyiben azt a böngésző támogatja.

Működik a Watch és a Locals ablak is, csak éppen nem túl érdekesek, hiszen property-kre vannak kihegyezve, amit sajnos itt többnyire metódusok helyettesítenek (például a TextBox osztálynak get_text() és set_text(..) metódusai vannak). Jól használható viszont az Immediate ablak, ahol közvetlenül hívhatunk meg függvényeket vagy kérdezhetjük le változók értékeit.

Trace

Ha a VS debug módban van, a trace metódus hívásával írhatunk az Output ablakba. Ha pedig szeretnénk formázni a kiírandó szöveget, akkor örülhetünk, hogy az AJAX Library-ben is van String.format metódus:

    Sys.Debug.trace( "Szia Világ!" );
    var txtName = new Sys.Preview.UI.TextBox( $get( "txtName" ) );
    Sys.Debug.trace( String.format( "txtName.text = '{0}'", txtName.get_text() ) );

Ha ugyanezt a szöveget a böngészőben is meg szeretnénk jeleníteni, akkor tegyünk egy TraceConsole id-val ellátott TEXTAREA tag-et az oldalra és ott is meg fog jelenni:

    <textarea id='TraceConsole' rows="30" cols="70"></textarea>

Ha bonyolultabb objektumokat szeretnénk trace-elni, akkor élvezhetjük a traceDump metódus szolgáltatásait, ami megpróbál a lehető legtöbbet kiírni az objektumról. Második paraméterként megadhatunk egy sztringet, ami segít eligazodni a trace üzenetek között:

    Sys.Debug.traceDump( txtName, "Szövegdoboz" );

Az én esetemben egy textboxról (<input id="txtName" type="text" value="MSDN Kompetencia Központ" />) ennyit tudott:

    Szövegdoboz {Sys.Preview.UI.TextBox}
            validated: null
            _updating: false
            _initialized: false
            _idSet: false
            _id: null
            _visibilityMode: 0
            _parent: null
            _validationMessage: null
            _validated: false
            _invalid: false
            _validators: null
            _valuePropertyName: null
            _keyPressHandler: null
            _changeHandler: null
            _text: null
            _element {INPUT - txtName}
            _oldDisplayMode: 

Ebben az a szomorú, hogy a text tulajdonságnak igenis volt értéke, ami nem más, mint a value attribútum értéke, amit ez itt nem tudott megjeleníteni, szóval csak óvatosan! smile_sad 

Ugyanez használható egyedi objektumokra:

    var person = { firstName: "György", lastName: "Balássy", year: 2007 };
    Sys.Debug.traceDump( person, "Én" );
    Én {Object}
            firstName: György
            lastName: Balássy
            year: 2007

És használható kivételek adatainak megjelenítésére is:

    try
    {            
        throw Error.notImplemented( "Ez még nincs kész." );
    }
    catch( ex )
    {
        Sys.Debug.traceDump( ex );
    }

Ebben pedig az az érdekes, hogy a Firefox többet árul el egy kivételről, mint az IE, az utóbbiban ugyanis nincs stack trace, de a Firefoxban van, sőt ott van fileName és lineNumber is:

    traceDump {Error}
            message: Sys.NotImplementedException: Ez még nincs kész.
            name: Sys.NotImplementedException
            stack: pageLoad([object Object],[object Object])@http://localhost:1531/PureClientAjax/Samples/DebugTrace.htm:41
    Sys$_Application$raiseLoad()@http://localhost:1531/PureClientAjax/Scripts/AjaxLibrary/MicrosoftAjax.debug.js:3758
    Sys$_Application$_doInitialize(240)@http://localhost:1531/PureClientAjax/Scripts/AjaxLibrary/MicrosoftAjax.debug.js:3795
    apply([object Object],[object Object])@:0
    (240)@http://localhost:1531/PureClientAjax/Scripts/AjaxLibrary/MicrosoftAjax.debug.js:50
    @:0

            fileName: http://localhost:1531/PureClientAjax/Samples/DebugTrace.htm
            lineNumber: 41

Ha már túl sokat naplóztunk, meghívhatjuk a clearTrace metódust a trace log takarítására:

    <input type="button" value="Trace törlése" onclick="Sys.Debug.clearTrace();" />

Assert

A Sys.Debug osztály utolsó metódusa az assert, amely akkor kiabál, ha a megadott feltétel hamis. Ha a hibaüzenet utáni harmadik paraméterben true-t adunk meg, a hiba ablakban a hibázó metódus kódja is megjelenik:

    var i = 1;    
    Sys.Debug.assert( i < 0, "Nem lehet pozitív!", true );

Ebben a menetben a piros pontot az IE kapja, mert karakterhelyesen megjeleníti a függvény teljes kódját, a FF viszont kicsapja belőle a kommenteket, áttördeli a kapcsos zárójeleket, ráadásul a magyar ékezetes karaketerek helyett csak kódjukat jeleníti meg, ami bizony nehezíti az olvasást, én ugyanis nem ezt írtam:

Talán így már nem annyira rémisztő a JavaScript írás smile_wink

 

Technorati tags: ,

Microsoft AJAX Library – ASP.NET nélkül

Ahogy az már a februári MSDN Kompetenciák Egyetemén is elhangzott, a Microsoft AJAX megoldásának egyik pillére a Microsoft AJAX Library. Ez a komponens lényegében három JavaScript fájl, amely az ASP.NET AJAX szerver oldali szolgáltatásaitól (UpdatePanel, webszolgáltatások stb.) függetlenül is használható, másként fogalmazva megáll a saját lábán, nem kell hozzá ASP.NET, sőt akár más szerver oldali technológiákkal (pl. PHP-vel) is összeházasíthatjuk.

Hogy bizonyítsuk a Microsoft AJAX Library szerver függetlenségét, ágyazzuk be nyers HTML oldalba! Lépések:

  1. A Microsoft AJAX Library script fájljatit tartalmazó ZIP letöltése és kibontása.
  2. Egy üres HTML oldal létrehozása.
  3. Szkript referenciák megadása a HTML oldalon. Amire szükség lehet:
    • Gyakran elég a MicrosoftAjax.js.
    • Ha extrákat is akarunk használni, akkor ne sajnáljuk kibányászni a Futures FTP-ből a preview scripteket. Kontrollok kezeléséhez a PreviewScript.js, csilivili animációkhoz pedig a PreviewGlitz.js kell.
    • Hibakereséshez nem baj, ha kéznél van a scriptek debug változatai is. Sőt, nálam az animációk csak a PreviewGlitz.debug.js fájllal mentek, a release verzióval nem!
  4. Az oldal alján inicializáljuk az AJAX Libraryt azzal, hogy meghívjuk a Sys.Application.initialize() metódust.
  5. Ellenőrzés: ha mindent jól csináltunk, akkor meg fog hívódni a pageLoad() metódusunk, amiben már a $get() függvény működni fog.

A teljes oldal kódja (feltételezve, hogy a szkriptek a Scripts mappában vannak):

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <title>Kezdőlap</title>
    
    <!-- Microsoft AJAX runtime -->
    <script type="text/javascript" src="Scripts/MicrosoftAjax.js"></script>
    <script type="text/javascript" src="Scripts/PreviewScript.js" ></script>
    
    <script language="javascript" type="text/javascript">
        // Automatikusan meghívódik, amikor az oldal betöltődött
        function pageLoad()
        {
            var txtName = new Sys.Preview.UI.TextBox( $get( "txtName" ) );
            Sys.Preview.UI.Window.messageBox( txtName.get_text() );
        }    
    </script>        
    
</head>

<body>
    <div>
        Az Ön neve:
        <input id="txtName" type="text" value="Szia Világ!" />
    </div>    

    <!-- Microsoft AJAX runtime inicializálása -->
    <script language="javascript" type="text/javascript">
        Sys.Application.initialize();
    </script>
</body>
</html>

Buktatók (ha nem működne):

  • Nem mindegy, hogy milyen sorrendben vannak a <script> tag-ek és az sem, hogy a <head> vagy a <body> részei.
  • A <script> nem működik úgy, ha önmagát zárjuk be, kell a különálló zárótag, tehát <script … /> nem jó, csak <script …></script> működik. Vajon miért? smile_sarcastic
  • Néhány dolog használható az AJAX Library-ben az initialize() meghívása nélkül is, de ha ott van, akkor legyen az oldal végén.

A legszebb az egészben, hogy az eredmény nem csak szerver, hanem böngésző független is (legalábbis amit az AJAX Library támogat), kipróbáltam Firefoxban, működik!

Mi mindent tud még az AJAX Library? Aki eljön a március 31-i Web Konferenciára, kaphat egy kis ízelítőt! smile_wink

 

Technorati tags: ,

ASP.NET AJAX Induló Készlet

A devPORTAL látogatottsági statisztikáit böngészve és az ASP.NET-tel ismerkedők visszajelzései alapján egyértelművé vált, hogy nagyon hasznos a 2006. februári MSDN Kompetenciák Egyeteme alapján összeállított ASP.NET Induló Készlet. Terveink szerint előbb-utóbb lesz hasonló ASP.NET AJAX témában is, azonban amíg az elkészül, addig itt a 2007. februári MSDN Kompetenciák Egyetemének anyagait összefoglaló linkgyűjtemény, ami segíthet az elindulásban:

Aszinkronitás a web világában (Balássy György)
ASP.NET 2.0 alkalmazás kiegészítése AJAX-szal (Gincsai Gábor)
Gazdag kliens és remix (mashup) alkalmazások (Nacsa Sándor, Kereskényi Róbert)
ASP.NET AJAX Client Library (Kereskényi Róbert)
ASP.NET AJAX Control Toolkit (Virág András, Kereskényi Róbert)

Lehet töltögetni 🙂

Technorati tags: ,

Saját item template készítése

Van egy aktuális webfejlesztési projektünk, ahol az egyes oldalakhoz tartozó közös funkcionalitás megvalósítása érdekében kénytelenek voltunk bizonyos szabályokat előírni, amelyeket az egyes ASPX oldalaknak követniük kell. Ezen túlmenően kialakítottunk egységes kódolási konvenciókat is, melyekhez az ASPX markup fájloknak és az ASPX.CS code behind fájloknak tartaniuk kell magukat. Mindezek együttesen azt eredményezték, hogy egy-egy oldal létrehozása után számos módosítást kötelezően el kell végezni a kód fájlban, melyek közül ha egyik-másik elmarad, elég nehézkesen derül ki tesztelésnél.

Ezért merült fel ötletként, hogy hozzunk létre egy új item template-et, amely a Visual Studio Add New Item ablakában megjelenve egy csapásra létrehozza a szükséges fájlokat, bennük a már módosított kóddal. Konkrétabban, a feladat egy ASPX és egy ASP.CS fájl létrehozása, továbbá az App_LocalResources mappában egy .ASPX.RESX és egy .ASPX.EN.RESX fájl létrehozása néhány kezdő értékkel.

Először is hozzunk létre egy olyan projekt típust, amelyhez item template-et szeretnénk készíteni – a mi esetünkben ez egy Web Site -, majd hozzuk létre benne a sablonizálni kívánt fájlokat.

Ezek után az első nehézséget az jelenti, hogy az ember nem találja a sablonizálásra szolgáló menüpontot a Visual Studioban. Pedig van, illetve nincs, szóval van is, meg nincs is. A File menüben lenne a helye, de nincs ott (pedig határozottan úgy emlékszem, hogy a bétában még ott volt). Ez ne zavarjon minket, nyissuk meg a ToolsOptions ablakot, majd a Commands fülről a File kategóriából keressük ki az Export Template… parancsot és rakjuk a helyére.

Az így elővarázsolt paranccsal indítsuk el az Export Template varázslót és értelemszerűen kövessük végig a lépéseit. A varázsló végeredménye egy ZIP fájl lesz, az az alábbi útvonalon: C:Users<TENEVED>DocumentsVisual Studio 2005My Exported Templates. Nagyon tetszett, hogy a varázsló készítői gondoltak arra, hogy egy item valójában több fájlból állhat, ugyanis a varázsló ezt állítja magáról:

All dependent files (including designer and resource files) will automatically be included with the selected item in the exported template.

A második nehézséget az jelenti, hogy sajnos ez így nem műküdik, konkrétan az ASPX oldalhoz tartozó resource fájlokat a varázsló nem tette magáévá. Pedig az ígéret szép szó! Ezt a problémát tehát kézzel kell megjavítanunk.

A varázsló által említett cél útvonal nagyon látványos, de a Visual Studio nem onnan dolgozik. Keressünk egy azonos nevű ZIP fájlt a következő mappában és nyissuk is meg a tartalmát: C:Users<TENEVED>DocumentsVisual Studio 2005TemplatesItemTemplates.

Keressünk benne egy .vstemplate kiterjesztésű állományt, másoljuk ki a ZIP-ből és nyissuk meg szövegszerkesztővel bátran, mert XML fájlról van szó. A <TemplateData> elemben láthatjuk a sablonhoz tartozó alap metaadatokat, ami viszont számunkra most fontosabb, az a <TemplateContent> elem, amely a sablonhoz tartozó fájlokat definiálja. Itt kellene megjelennie a resource fájljainknak.

Mivel a fájl elején van névtér hivatkozás, a Studio megpróbál IntelliSense-szel segíteni. A harmadik nehézséget az jelenti, hogy az IntelliSense nem jó, olyan elemeket kell felvennünk a fájlba, amit az IntelliSense nem ismer, konkrétan egy <Folder> tag-et jónéhány attribútummal. A hivatkozott mappát – nálunk App_LocalResources – a ZIP fájlon belül is létre kell hozni és a resource sablonokat azon belül kell tárolni, hogy a Studio majd onnan vegye ki.

A negyedik nehézséget az okozta, hogy természetesen minden alkalommal más nevet akarunk adni a létrehozandó fájlnak és ezzel együtt a létrehozandó osztálynak is. Ehhez használhatunk placeholder sztringeket, amelyekről találunk leírást az MSDN-ben. Például a $fileinputname$ az általunk megadott fájl nevet fogja jelenteni, a $safeitemname$ pedig az abból képzett olyan nevet, amit akár osztálynévként is használhatunk. Az XML fájlban a ReplaceParameters="true|false" attribútum megadásával kérhetjük a Studiot, hogy cserélgesse ki ezeket a placeholdereket.

Végül már csak egy ötödik nehézség maradt, ami már inkább szépséghiba: új item létrehozásakor a Studio megnyitotta az ASPX fájlt és az ASPX.EN.RESX fájlt szerkesztésre. Mivel legtöbb esetben nem éppen erre a kettőre van szükség, kicsit variálnunk kell rajta, amit természetesen az XML-ben tehetünk meg: az OpenInEditor="true|false" attribútummal.

Ténykedésünk eredményeként a módosított .vstemplate fájl lényegi része ez lett:

  <TemplateContent>
    <References />
    <ProjectItem TargetFileName="$fileinputname$.aspx" OpenInEditor="true" ReplaceParameters="true">MyPage.aspx</ProjectItem>
    <ProjectItem TargetFileName="$fileinputname$.aspx.cs" ReplaceParameters="true">MyPage.aspx.cs</ProjectItem>
    <Folder Name="App_LocalResources" TargetFolderName="App_LocalResources">
      <ProjectItem TargetFileName="$fileinputname$.aspx.resx" ReplaceParameters="true" OpenInEditor="false">MyPage.aspx.resx</ProjectItem>
      <ProjectItem TargetFileName="$fileinputname$.aspx.en.resx" ReplaceParameters="true" OpenInEditor="false">MyPage.aspx.en.resx</ProjectItem>
    </Folder>
  </TemplateContent>

Végezetül néhány tapasztalati tanács:

  1. Úgy vettem észre, hogy a VS hajlamos cache-elni a template-et, ezért a sablon módosítása esetén érdemes újraindítani a Visual Studiot.
  2. Bár az XML-ben és a Studioban nincs lehetőség a sablon verzionálására, használhatjuk a <Description> tag-et arra, hogy abban megadjunk egy verziószámot, ami VS-ben is meg fog jelenni.
  3. Célszerű backupot készíteni az elkészült sablonról, mert nagyon elbújik ebben a mappában. Így gépünk újratelepítése vagy új projekt tag bevonása esetén is kéznél lesz. Ha lehetjük, tegyük a projekt többi részével együtt source control alá.

 

Technorati tags: ,

Objektum inicializálás LINQ-ban

Aki unja, hogy VS 2005-ben prop-tab-tabbal hozzon létre tulajdonságokat, biztos örömmel olvassa Scott Guthrie március 8-i blogbejegyzését, amelyben a C# 3.0 automatikus tulajdonsággyáráról szól. Ezentúl nem kell időt töltenünk a semmitmondó privát mezők gépelgetésével, sőt kerülgetnünk sem kell azokat, ilyen egyszerűen készíthetünk egy osztályt három tulajdonsággal (mondom tulajdonsággal és nem mezővel!):


    public class Kollega
    {
        public string Vezeteknev { get; set; }
        public string Keresztnev { get; set; }
        public string Varos { get; set; }
    }

Sőt, ezeket a tulajdonságokat egy kényelmesebb szintaxissal lehet inicializálni, ráadásul nem csak egyesével, de gyűjteményben is:


    List<Kollega> kollegak = new List<Kollega>();

    kollegak.Add( new Kollega { Vezeteknev = "Balássy", Keresztnev = "György", Varos = "Budapest" } );
    kollegak.Add( new Kollega { Vezeteknev = "Dávid", Keresztnev = "Zoltán", Varos = "Budapest" } );
    kollegak.Add( new Kollega { Vezeteknev = "Gincsai", Keresztnev = "Gábor", Varos = "Nyíregyháza" } );
    kollegak.Add( new Kollega { Vezeteknev = "Kereskényi", Keresztnev = "Róbert", Varos = "Nyíregyháza" } );
    kollegak.Add( new Kollega { Vezeteknev = "Virág", Keresztnev = "András", Varos = "Kecskemét" } );

Folytassuk ott, ahol Scotty abbahagyta, hozzuk össze ezt a LINQ-kel! Használhatjuk a LINQ-et arra, hogy lekérdezzünk elemeket a fenti gyűjteményből:

    var pestiek = from k in kollegak 
                  where k.Varos == "Budapest" 
                  select k.Vezeteknev;

    foreach( string p in pestiek )
    {
        Console.WriteLine( p );
    }

Ebben az esetben a pestiek nevű változó lényegében egy string gyűjteményt fog tartalmazni. (Ez durva csúsztatás, de nekünk most a lekérdezés visszatérési értéke a lényeg.)

Ha nem egyetlen string értékkel szeretnénk visszatérni, hanem többel, konstruálhatunk belőle egy ojjektumot a selectben:

    var szabolcsiak1 = from k in kollegak 
                       where k.Varos == "Nyíregyháza" 
                       select new { k.Vezeteknev, k.Keresztnev };

Ebben az esetben viszont már nem tudjuk megmondani kódolás közben, milyen típusú lesz a visszatérési érték, tehát gondban vagyunk a foreachnél. Erre találták ki a vart! A C# továbbra is egy erősen típusos nyelv, a var itt nem olyan, mint JavaScriptben, vagy VB-ben a variant, itt a var csak annyit jelent, hogy olyan típust használj kedves fordító, ami az egyenlőségek jobb oldaláról kijön:

    foreach( var s in szabolcsiak1 )
    {
        Console.WriteLine( "{0} {1}", s.Vezeteknev, s.Keresztnev );
    }

Sőt, mivel teljesen új objektumokat hozunk létre, aminek a típusát a select utáni rész alapján definiálja a fordító, semmi akadálya, hogy adjunk neveket a tulajdonságainak:

    var szabolcsiak2 = from k in kollegak
                       where k.Varos == "Nyíregyháza"
                       orderby k.Vezeteknev
                       select new { Csaladnev = k.Vezeteknev, Utonev = k.Keresztnev };

    foreach( var s in szabolcsiak2 )
    {
        Console.WriteLine( "{0} {1}", s.Csaladnev, s.Utonev );
    }

Íme, micsoda fegyvert ad a kezünkbe az object initializer szintaktika és a LINQ összeházasítása!

A korábbiakkal ellentétben ez a kód nem fut a 2006. májusi LINQ preview-val, de a 2007. márciusi Orcas CTP-vel megy remekül, ott lehet kísérletezni.

 

Technorati tags: ,