2009. október havi bejegyzések

It’s time to kill – bugs

Halloween különkiadás a Channel 9 csapattól, ami bemutatja, mi történhet, ha egy sötét, ködös estén az embert egy határidőkkel küzdő szoftverfejlesztővel hozza össze a sors.

WARNING: This video contains blood, gore and one extremely frightening software developer.

http://channel9.msdn.com/posts/LauraFoy/Bug-Killer–A-Channel-9-Halloween-special/

Reklámok

Visual Studio 2010 Help Library Manager

Aki telepítette már a Visual Studio 2010 Beta 2-t, annak bizonyára feltűnt, hogy a telepítés végén lévő link, amivel az offline MSDN Library-t szoktuk telepíteni, nem kattintható. Most még csak disabled, de mire a VS 2010 RTM lesz, minden bizonnyal teljesen el fog tűnni ez a menüpont onnan.

A Dev10 Wave-vel (Visual Studio 2010, .NET4) ugyanis új MSDN-t is kapunk. Az online MSDN már 10 napja megváltozott, piros helyett immár kék a menő. Ennél kicsit hasznosabb, hogy végre kivezették azokat a funkciókat, amik korábban csak URL trükközéssel voltak elérhetőek. Például, ha egy MSDN-es URL végére odaírtuk, hogy (loband), akkor egy szkriptek nélküli oldal töltődött be, méghozzá villámgyorsan. Most már nem kell URL-t trükközni, a jobb alsó sarokban választhatjuk a ScriptFree nézetet. Ebben a nézetben egyedül azt nem szeretem, hogy minden nyelven megmutatja a metódus szignatúrákat és nem lehet szűrni. Ennél egy fokkal barátságosabb az új Lightweight nézet, ahol van szűrés, olvasható formázás, de még így is jó tempóban dolgozik.

Ami az offline MSDN-t illeti, azért fog eltűnni a Studio telepítő végéről az MSDN telepítő link, mert egy teljesen új komponens veszi át a helyét, a Help Library Manager. Őt a Start menüben, vagy a Visual Studio 2010 Help menüjében találjuk meg Manage Help Settings néven. Ha elindítjuk, először meg kell adnunk az offline súgó célkönyvtárát:

Help Library Manager - Location

Az OK gombra kattintva egy menü jön elő:

Help_Library_Manager-Menu

Itt a Find content online linkre kattintva böngészhetünk a letölthető tartalmak között:

Help_Library_Manager-Find_content_online

Én csak a .NET Framework 4.0-t választottam ki, majd az Update gombra kattintva 900 MB letöltése következett 38 komponens formájában. Ezután egy kis Merge indexing piszmogás és készen is vagyunk.

A Start menüből a Visual Studio 2010 Documentation menüpontot választva azonban nem a szokásos CHM-es help nézegető jön elő, hanem a kedvenc böngészőnk, a jobb alsó sarokban pedig elindul a Microsoft Help Listener, ami igencsak egy webszervernek tűnik és a böngészőben lévő URL-ek alapján a 80-as porton figyel. Ha véletlenül ül már ott egy processz, akkor a Connecten leírtak szerint némi registry matatással átköltöztethetjük a súgót másik portra.

Elsőre nagyon furcsa, hogy nincs Index fül, mindenre keresni kell és bár a keresés gyors, a találatok megjelenítése nem túl praktikus. Reméljük sokat javul még ez az RTM-ig, van mit szokni rajta.

Futtatás közvetlenül Solution Explorerből

Az egyik futó projektünkben elég sok batch fájlt írtunk a szokásos napi feladatok automatizálásra és miután meguntam, hogy a Visual Studioból nem lehet közvetlenül futtatni ezeket, hozzáadtam egy új menüpontot a Solution Explorer helyi menüjéhez.

Az első lépés, hogy a Tools –> External Tools ablakban fel kell vennünk egy új sort ezekkel a paraméterekkel:

External tools ablak

Így lesz egy Run with CMD menüpontunk a Tools menüben, amit nézzünk is meg, mert később szükségünk lesz arra, hogy a csoportján belül hányadik az új menüpontunk. Mivel ennek még körülményes a használata, lépjünk eggyel tovább. Szabjuk testre az eszközsávokat: View –> Toolbars –> Customize… (legalul). Kapcsoljuk be a Context Menus sort a Toolbars fülön:

Customize toolbars

Ennek hatására megjelenik az eszközsávokat testreszabó eszközsáv (na ez jó :). Hagyjuk nyitva a Customize ablakot és az eszközsávot tologassuk el úgy, hogy a lenyitott Tools menü ne fedje el a Project and Solution Context Menus elemet:

Project and Solution Context Menus toolbar

Nyissuk ki a Tools menüt és keressük ki az új parancsunkhoz tartozó External command sort – ugye mondtam, hogy meg kell jegyezni, hányadik a miénk 😉 Álljunk fölé az egérrel és a Controlt nyomva (mert csak másolni akarunk, nem mozgatni) dobjuk be ezt a sort a Project and Solution Context Menus menü Item ágába:

 Project and Solution Context Menus toolbar - Item

Zárjuk be a Customize ablakot, kész az új menüpontunk a Solution Explorerben. Hasonlóan létrehozhatunk menüpontot az SQL szkriptek közvetlen futtatására, csak ott a cmd.exe helyett mutassunk az sqlcmd.exe-re és ne felejtsük el az Arguments ablakot kitölteni.

CSS és Javascript minimalizálás MSBuildből

Az ASP.NET Web Site típusú projekt egyik tulajdonsága, hogy nem tartozik hozzá project fájl. Ez ugyan többnyire előny, mert kényelmes, nekem most éppen hátrány, mert MSBuilddel akarom automatizálni nem csak a fordítási folyamatot, hanem a web.config production beállításokkal történő frissítését, a felesleges könyvtárak törlését, továbbá a CSS és Javascript fájlok minimalizálását is.

Mivel a szóban forgó alkalmazás Visual Studio 2008 alatt van és gyors megoldás kellett, ezért nem ástam bele magam a szép új MSDeployba, inkább feltettem a Web Deployments Projectset. Ez gyakorlatilag azt tudja, hogy egy Web Site projekthez rendel egy MSBuildes projekt fájlt, továbbá telepít egy rakás MSBuild taskot, ami közül néhányat grafikus felületről lehet paraméterezni.

Ha végigjutottunk a Next-Next-Finish telepítőn, akkor ne a New Project menüben keresgéljünk, hanem a Solution Explorerben a Web Site projektünkön jobb klikk és ott Add Web Deployment Project… Ezek után ne várjunk sokat, létrejön egy üres projekt, aminek a Properties ablakában szinte mindent be tudunk állítgatni. Ez többnyire magától értetődő.

A Deployment fülön tudjuk beállítani, hogy a web.config fájlunkban lévő értékek (pl. appSettings) melyik másik fájlnak a tartalmára cserélődjenek ki. Itt egy trükkre hívnám fel a figyelmet: config section groupokat nem lehet megadni. Azaz például ne próbáljuk a system.net/mailSettings szekciót cserélni, mert az épp section group, hanem az alatta lévő system.net/mailSettings/smtp szekcióval próbálkozzunk:

WDP_Deployment_tab

Ha mindent szépen beállítgattunk, akkor úgy lehet kipróbálni, hogy megbildeljük a deployment projektet.

Ám ezzel még nincs vége, ha ugyanis a deployment projekten jobb egérgombbal kattintunk és azt mondjuk, hogy Open project file, és minden bátorságunkat összeszedve belefirkálunk a forrásba, akkor még jobban felturbózhatjuk a build folyamatot.

Tekerjünk az aljára és szabadítsuk ki a kikommentezett AfterBuild szekciót. Első lépésként jó lenne megszabadulni azoktól a mappáktól és fájloktól, amik a fordítás és a web.config feldolgozása után már amúgy sem kellenek. Ehhez mindössze ezt kell beleírnunk ebbe a szekcióba:

  <Target Name="AfterBuild">
    <Message Text="-- Removing unnecessary files and folders..." Importance="high" />
    <RemoveDir Directories="$(OutputPath)App_Themes" />
    <Delete Files="$(OutputPath)web_appsettings.production.config;$(OutputPath)web_connectionstrings.production.config;$(OutputPath)web_smtp.production.config" />
  </Target>

A RemoveDir taskkal törölhetünk egy mappát, a Delete taskkal pedig fájlokat, akár többet is. A Message arra jó, hogy “fordítás” közben látszódjon a konzolon, hogy mi is történik, Importance=”high” pedig arra kell, hogy a saját üzeneteink kiemelt színnel jelenjenek meg.

Itt egyébként tetszőleges parancsot futtathatunk, ha az Exec taskot használjuk. Ha van például a projektünkben egy UserUpload mappa és az a source control miatt read-only, akkor így szedhetjük le róla ezt az attribútumot a kimenetben:

  <Exec Command="attrib -R /S &quot;$(OutputPath)UserUpload*.*&quot;" />

Ugyanígy futtathatunk tetszőleges külső alkalmazást, például olyat is, ami a Javascript fájljainkat minimalizálja. Én egy ennél igényesebb megoldást akartam és ezért döntöttem a Microsoft AJAX Minifier mellett, ahhoz ugyanis tartozik MSBuild task! Az AJAX Minifier telepítője egy MSI, én pedig nem akartam a projektben minden résztvevő kollégával ezt letölteni és telepíttetni, ezért miután a saját gépemen feltelepült, átmásoltam a szükséges fájlokat egy _Build nevű mappába a Web Site projektben. Ezt a mappát természetesen ugyanúgy letöröltetem a RemoveDir taskkal…

WDP_AJAX_Minifier

Importálnunk kell az AJAX Minifierhez tartozó MSBuild taskot, ami egyébként az AjaxMin.tasks fájlban van definiálva. Ehhez ezt kell beírnunk még az AfterBuild szekció elé:

  <Import Project="..Web_BuildAjaxMinajaxmin.tasks" />

Következő lépésben az AfterBuild szekción belül definiáltam ItemGroupot, amiben JavaScriptFiles néven összefogtam az összes tömörítendő fájlt:

  <ItemGroup>
    <JavaScriptFiles Include="$(OutputPath)Static*.js" Exclude="$(OutputPath)Static*.min.js" />
  </ItemGroup>

Ezután már csak meg kellett hívni a tömörítő taskot:

  <AjaxMin SourceFiles="@(JavaScriptFiles)" SourceExtensionPattern=".js$" TargetExtension=".min.js" />

Ez létrehozza az ize.js fájl mellé az ize.min.js fájlt. A feleslegessé vált eredeti állományt le kell törölnünk, a tömörítettet pedig át kell neveznünk:

  <Delete Files="$(OutputPath)Staticize.js" />
  <Exec Command="rename &quot;$(OutputPath)Staticize.min.js&quot; ize.js" />

Ez eddig hibátlan, sajnos azonban a Microsoft AJAX Minifier nem tud CSS-t optimalizálni. Ezért szemrebbenés nélkül letöltöttem a YUI Compressor .NET-es változatát, ahhoz ugyanis szintén van MSBuild task. A YUI Compressor nem csak CSS-t, hanem Javascriptet is tud tömöríteni, de ScottGu szerint a sajátjuk jobb, és mivel az én tesztem is ezt támasztotta alá, ezért a hibrid megoldás mellett döntöttem.

A fenti képen látszik, hogy a YUI Compressor fájljait is kicsomagoltam a _Build mappába, majd az AjaxMin.tasks mintájára faragtam egy YUICompressor.tasks fájlt, ami mindössze ennyiből áll:

  <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    <UsingTask TaskName="CompressorTask" AssemblyFile="Yahoo.Yui.Compressor.dll" />
  </Project>

Természetesen használat előtt ezt is importálni kell:

  <Import Project="..Web_BuildYUICompressorYUICompressor.tasks" />

És az ItemGroupot is kiegészítettem egy CssFiles változóval:

  <ItemGroup>
    <JavaScriptFiles Include="$(OutputPath)Static*.js" Exclude="$(OutputPath)Static*.min.js" />
    <CssFiles Include="$(OutputPath)Staticize.css" />
  </ItemGroup>

Ennyi bemelegítés után a CSS optimalizálás már csak ennyiből áll:

  <CompressorTask
    CssFiles="@(CssFiles)"
    DeleteCssFiles="True"
    CssOutputFile="$(OutputPath)Staticize.css"
    CssCompressionType="YuiStockCompression"
    PreserveAllSemicolons="False"
    DisableOptimizations="Nope"
    EncodingType="Default"
    LineBreakPosition="-1"            
    LoggingType="ALittleBit"
    ThreadCulture="en-au"
    IsEvalIgnored="false" />

Szerencsére itt van olyan opció (DeleteCssFiles), amivel az optimalizált verzió egyből felülírja az eredeti fájlt.

Végül már csak egyetlen lépés maradt hátra, egy rövidke .cmd fájl elkészítése, amire bármikor duplán kattintva lefordul a teljes solution (a Web Site projekt által használt osztálykönyvtárak is), és természetesen lefut a Web Deployment Project is. Ebben a batch fájlba egyetlen sor került:

  "%WinDir%Microsoft.NETFrameworkv3.5MSBuild.exe" /target:Build 
/property:Configuration=Release MySolution.sln 
/p:AspNetConfiguration=Release

ASP.NET AJAX 4: Kevesebb töltögetés

Az ASP.NET csapat nemrég elérhetővé tette a Microsoft AJAX Library Preview 6 változatát, amivel egy rakás olyan újdonság vált elérhetővé, amellyel végül sokkal kevesebb Javascriptet kell a weboldal látogatóira rátukmálnunk.

Daraboljuk fel

Az egyik legfájóbb probléma az ASP.NET AJAX 3.5 alkalmazásánál, hogy viszonylag sok és viszonylag nagy Javascript fájlok folynak le a kliensre és erre nem igazán tudunk hatással lenni. Hiába használtunk csak egy kis funkciót a nagy ASP.NET AJAXból vagy akár csak a Microsoft AJAX Libraryből, jött vele minden. A jó hír az, hogy az ASP.NET 4.0-tól (már a béta1-től) kezdve több kis Javascript fájl van, dokumentálták, hogy melyik mit tud és hogyan függnek egymástól:

Microsoft_AJAX_Library_refactored

Rakjuk össze

Persze aki foglalkozott már teljesítménynöveléssel rögtön a fejéhez kap, hogy így a kliensnek sok fájlt kell letölteni, az sok HTTP kérés, ami még akkor is lassú, ha mindegyik 304 (Not modified) üzenettel tér vissza. Korábban volt egy kezdeményezés az AJAX Control Toolkit fejlesztőitől egy ToolkitScriptManager osztály formájában, de ezt kevesen ismerték és még kevesebben használták. A jó hír az, hogy a beépített ScriptManager osztály is támogatja a script combiningot, csak annyi dolgunk van, hogy a <Scripts> gyermek elemeit körbevesszük egy <CompositeScript> elemmel. Ez már a 3.5 verzióban is működik, ha explicit módon adjuk meg a szkripteket és akkor is csak azokra a szkriptekre, amelyek használják a ScriptManagert. Kilógnak például a validátorok, akik előbb születtek, mint a ScriptManager. Szerencsére a 4.0 verzióban már ez is jól fog menni mind a ScriptResource.axd-vel, mind pedig a WebResource.axd-vel leküldött fájlokra.

Nyomjuk össze

Ha összerakunk jó sok szkriptet egybe, akkor ugyan csökken a HTTP kérések száma, de a letöltendő szkript mennyiség még nagy. Szerencsére a Preview 6-ban már van egy Microsoft AJAX Minifier, ami nem csak, hogy jobban tömörít, mint a JSMin, a Packer és a YUI Compressor, de ráadásul MSBuild taskként be is tudjuk építeni a build folyamatunkba. Erről majd írok nemsokára, mert nagyon egyszerűen megy, az egyetlen baja, hogy csak Javascriptet tud összenyomni, CSS-t nem 😦

Töltsük máshonnan

Ha ideáig eljutottunk, akkor már csak azt töltik le a felhasználók, amire szükségük van, csakhogy azt minden egyes ASP.NET AJAXot használó webhelyről újra és újra megteszik. Ez nekik lassúság, a webhelyek gazdáinak pedig sávszélesség, amiért fizetniük kell. Szerencsére a Microsoft létrehozott egy Content Delivery Networkot (CDN) és erre a CDN-re felpakolta a Microsoft AJAX Library fájljait és a jQuery Library-t. Nekünk csak annyi dolgunk van, hogy a Microsoft FQDN-jét adjuk meg forrásként, az infrastruktúra pedig gondoskodik arról, hogy valóban a legközelebbi szerverről töltődjenek le a fájljaink. Ráadásul ha már egy Microsoft CDN-t használó webhelyet meglátogatott a felhasználó, akkor a szkriptek ott lesznek a böngészője gyorsítótárában és a következő MS CDN-t használó webhelynél már le sem kell tölteni ezeket.

Csak akkor, ha kell

A Preview 6-ban megjelent egy script loader komponens, ami lehetővé teszi, hogy egyrészt ne nekünk kelljen foglalkoznunk azzal, hogy a library egyes szkriptjei hogyan függnek egymástól, másrészt akkor és azt a részét töltsük le a library-nek a kliensre, amire éppen akkor és ott szükség van. Elég csak a script loaderre hivatkoznunk az oldal tetején:

  <script src="http://ajax.microsoft.com/ajax/beta/0910/Start.js" type="text/javascript"></script>

Kódban pedig elég megadnunk, hogy melyik komponensre van szükségünk. Ha például DataView-val akarunk adatot kötnünk, nem kell tudnunk, hogy melyik .js fájlban tanyázik, elég ennyi írnunk:

  Sys.require( Sys.components.dataView ); 

Amint letöltődött a szkript fájl, a rendszer meghívja az onReady eseménykezelőt, ahol már használhatjuk is a komponenst:

  Sys.onReady( function() 
{
Sys.create.dataView("#myDiv",
{
data:countries

});
});

Ütős lesz a következő .NET Framework, nem véletlenül lett 4.0 és nem 3.6 🙂

ASP.NET alkalmazás előfordítása parancssorból

Tudjuk, hogy egy ASP.NET alkalmazást nagyon egyszerű közzétenni egy webszerveren, elég csak felmásolnunk a forrásfájlokat, a fordításról pedig az ASP.NET futtatókörnyezet automatikusan gondoskodik. Ez ugyan működik, de mint ahogy egy desktop alkalmazást sem adunk a felhasználóknak forráskód formájában, itt is szebb az olyan megoldás, ahol a szerverre már csak a lefordított DLL-ek kerülnek fel.

Az ASP.NET runtime a fordításhoz az aspnet_compiler.exe-t használja, ami a .NET Framework része. Ez gondoskodik arról, hogy a C# és VB fájljainkat a megfelelő csc.exe vagy vbc.exe fordítók dolgozzák fel. Az aspnet_compiler eredménye futtatható, de nem túl barátságos, egy rakás fájlból áll. Alapértelmezés szerint még az ASPX és ASCX fájljainkból is kipucolja a markupot, ami telepítés és üzemeltetés szempontjából barátságos, cserébe nem fogunk tudni online beleszerkeszteni a fájlokba.

Ha össze akarjuk gyúrni az egész webalkalmazásunkat egyetlen DLL-be, akkor szükségünk lesz még az aspnet_merge.exe-re is. Ez az eszköz korábban külön volt letölthető (az ASP.NET Induló Készletben is így szerepel), ma már azonban az SDK része. Képes a compiler kimenetét egyetlen fájlba összeállítani, annak fix nevet adni, verziózni, erős névvel ellátni.

Mindezt egyetlen szkriptben meg lehet írni és később 2 kattintás futtatni. Először is kellenek az eszközök elérési útjai, a bemeneti és a kimeneti mappa:

  set FXDIR="C:WindowsMicrosoft.NETFrameworkv2.0.50727"
  set SDKDIR="C:Program FilesMicrosoft SDKsWindowsv6.0ABin"
  set SOURCEDIR=Web
  set TARGETDIR=PrecompiledWeb

Takarítsuk ki a célkönyvtárat (erre egyébként az aspnet_compiler /f kapcsolója is képes, de biztos, ami biztos):

  rd /s /q %TARGETDIR%

Jöhet a fordítás:

  %FXDIR%aspnet_compiler.exe -v / -p %SOURCEDIR% -f -fixednames %TARGETDIR%

Majd az összegyúrás:

  %SDKDIR%aspnet_merge.exe -o My.Web.dll %TARGETDIR% -a -r

A paraméterek jelentését mindenki kiderítheti, ha Visual Studio Command Promptban valamelyik eszközt a –? kapcsolóval futtatja. Akit pedig egy bolondállóbb változat érdekel, innen letöltheti a teljes szkriptet.

Aki pedig kevésbé szeret szkriptelni, annak érdemes megismerkedni a Web Deployment Project-tel vagy a nemrég megjelent Web Deployment Tool (MSDeploy) eszközzel.

ASP.NET AJAX 4: Kliens oldali adatkötés – Sys.Observer

A cikksorozat előző részeiben ([1], [2]) az egyszeri adatkötéssel ismerkedtünk, ami sok esetben nagyon hasznos, de mégis az az igazi, ami a megváltozott adatot automatikusan képes frissíteni a felhasználói felületen. Ehhez arra van szükségünk, hogy észrevegyük, ha egy objektum valamelyik tulajdonsága megváltozik, ami lássuk be, JavaScriptben nem is olyan egyszerű feladat.

JavaScriptben ugyanis nincsenek property-k, legalábbis nem a .NET-es értelemben, azaz nincs lehetőségünk getter és setter metódusok írására. Ugyan van egy javasolt elnevezési konvenció – amit egyébként a Microsoft AJAX Library osztályai követnek is – miszerint írjunk get_ és set_ kezdetű metódusneveket, de ez nagyon körülményes megoldás lenne olyan esetekben, amikor primitív adatstruktúrákkal dolgozunk. Képzeljünk el egy webszolgáltatástól JSONban visszakapott Person objektumokból álló tömböt, hol van abban get_ és set_ metódus? Sehol.

Hasonló problémákra az elterjedt megoldás az observer tervezési minta használata: adott egy publisher, akinek a birtokában van az adat és ő szól az érdeklődő subscribereknek, ha az adat megváltozott. Egy JSONos objektum tömb valóban tartalmazza az adatot, csak éppen nem képes szólni, ha az megváltozik. Természetesen nincs akadálya, hogy felruházzuk a tömbünket ilyen funkciókkal, de ha ezt minden esetben nekünk kell megírnunk, akkor az egyrészt nagyon sok munka (JavaScriptben a sima “sok”=”brutál sok”), másrészt nagyon idegesítő lesz a sokféle implementációval vacakolni.

Itt jön a képbe a Sys.Observer osztály, ami képes egy tetszőleges objektumot igazi publisherré tenni.

Vegyük a korábban már látott országokat egy tömbben:

  var countries = [
        { Name: 'Austria', Capital: 'Vienna' },
        { Name: 'Australia', Capital: 'Canberra' },
        // És így tovább...
    ];

És jelenítsük meg a már jól ismert DataView vezérlővel deklaratív módon:

  <ul 
    class="sys-template" 
    sys:attach="dv" 
    dv:data="{{ countries }}">
    <li>
        {{ Name }} ({{ Capital }}) 
    </li>
  </ul>

Készítsünk két linket, amivel a forrás adatokat manipuláló függvényeket fogjuk hívni:

  <a href="#" onclick="onAdd()">Hozzáad</a> 
  <a href="#" onclick="onDelete()">Töröl</a>

Ezek után, ha az onAdd és onDelete függvényekben megpróbáljuk közvetlenül módosítani a countries változót, akkor hiába várjuk, hogy a módosítások megjelenjenek a felületen. Nosza vessük be a Sys.Observer osztályt és tegyük a countries gyűjteményt observable-lé:

  Sys.Observer.makeObservable(countries);

Majd figyeljük meg például a Visual Studio Watch ablakában, hogy hogyan változott a saját kis primitív adatstruktúránk: Sys.Observer.makeObservable eredménybe

A gyűjteményünk kapott néhány metódust és ha ezeket használjuk az adatok módosítására, akkor arról minden subscriber értesülni fog. A metódusok nevei eléggé magukért beszélnek, egyedül annyit emelnék ki, hogy ha nem akarjuk az értesítést azonnal elküldeni – például mert több tulajdonságot módosítunk sorban – akkor a módosítások előtt hívjuk meg a beginUpdate, a végén pedig az endUpdate metódust. Az előbbi felfüggeszti az értesítés küldést, az utóbbi pedig elküldi őket. A makeObservable metódust egyszerűbb esetekben akár el is hagyhatjuk, ekkor azonban a Sys.Observer osztály “statikus” metódusainak első paraméteréül át kell adnunk, hogy melyik objektummal dolgozzanak.

Visszatérve a fenti példára, írjuk meg az onAdd és onDelete metódusokat az új metódusok segítségével:

  function onAdd()
  {
    countries.add({ Name: 'France', Capital: 'Paris' });
  }

  function onDelete()
  {
    countries.removeAt(9);
  }

Ezzel készen is vagyunk, ha kipróbáljuk látni fogjuk, hogy a gyűjtemény módosításai azonnal látszódnak a felhasználói felületen, nem kell külön frissítenünk. Már csak azzal vagyok adós, hogy miért? A megoldás pedig igen egyszerű: a DataView okos osztály, észreveszi, hogy observable adatforrással dolgozik és automatikusan feliratkozik a változásaira, nekünk ezzel nem kell foglalkoznunk.

Érdemes kipróbálni, hogy mi történik, ha nem a gyűjteményen, hanem a gyűjtemény egyik elemén módosítunk, például így:

  countries[7].Name = 'Magyarország';

Megmondom már most: semmi, a DataView rá se bagózik. De hogy mindennek mi köze a live bindinghoz, azt azonban csak legközelebb árulom el…

A cikkhez tartozó forráskód letölthető innen.