Tag Archives: Ajax

Microsoft CDN változások

Történt néhány örömteli változás a Microsoft Content Delivery Network háza táján:

1. Felkerült a jQuery 1.4.3 és 1.4.4 verziója nem csak debug, hanem minimalizált változatban is.

2. Sőt, ezekhez felkerültek a –vsdoc.js fájlok is, amivel felokosíthatjuk a Visual Studio IntelliSense-t, hogy a legújabb verzió szépségeit is ismerje. Végre nem kell vadászni, hanem minden beszerezhető egy helyről.

3. Ami a legjobb hír, hogy végre nem a microsoft.com tartomány alatt, hanem új helyen, az ajax.aspnetcdn.com néven érhető el a CDN. Ez azért nagyon pozitív, mert végre az egyéb Microsoftos oldalak látogatásakor összeszedett sok-sok cookie nem utazik, amikor csak a JavaScript fájlokat szeretnénk villámgyorsan letölteni a CDN-ről. Állítólag ez akár 20% teljesítmény-növekedést is eredményezhet.

Ez a 3. pont egy elég jogos problémát orvosol, így már igazán nem látom akadályát, hogy még több webhely kezdje el használni a CDN-t és innen töltse le a gyakori szkript fájlokat. Van még kifogás?

A CDN-en elérhető szkriptek teljes listája megtalálható a http://www.asp.net/ajaxlibrary/cdn.ashx oldalon.

Technorati-címkék: ,,
Advertisements

Blokkolás aszinkron postback idejére

Beismerem, már a cím is elég visszás, hiszen az aszinkron postback, az Ajax egyik eredeti célja az volt, hogy a felhasználó kényelme érdekében a postback művelet a háttérben történjen, és ne blokkolja a felhasználói felületet. Ennek ellenére sajnos időnként mégis szükség van arra, hogy az Ajaxos hívás idejére letiltsunk bizonyos vezérlőket, vagy legalábbis a képernyő egyes részeit.

Ehhez nagyon hasznos segítség lehet a jQuery, amit biztosan nem kell bemutatni. Legjobban azt szeretem benne, hogy végtelen mennyiségű plugin érhető el hozzá, (bár egyben ez a hátránya is, gyakran a megfelelő plugin kiválasztása tovább tart, mint utána a beépítése az alkalmazásba), melyek közül a fenti feladatra nekem legjobban a jQuery BlockUI plugin vált be. A letölthető JavaScript fájl mindössze 16KB, de ha vesszük magunknak a fáradtságot és minimalizáljuk, akkor mindössze 7.59 KB-ot foglal, amit még a webszerver tovább tömöríthet, így a kliensnek máris csak 3.6KB-ot kell letölteni.

Ezt a plugint felhasználva a teljes ablakunk (amit itt a példában egy id=”main” attribútummal ellátott div valósít meg) blokkolása egy üzenettel, mellette egy forgó képpel, félig átlátszó szürke átfedéssel (overlay) és egy fehér, keretezett ablakkal középen mindössze ennyi:

  $("#main").block({
    message: ' <img src="progress.gif" /> Feldolgozás folyamatban...',
    css: { border: '1px solid black', width: '200px', padding: '20px', 
color: 'black', 'background-color': 'white' }, overlayCSS: { backgroundColor: '#f2f5f8', opacity: 0.9 } });

A blokkoló üzenet eltűntetése még egyszerűbb:

  $("#main").unblock();

Már csak arra van szükségünk, hogy ezeket a kódokat aszinkron postback esetén hívjuk meg. Szerencsére az ASP.NET Ajax Library PageRequestManager kliens oldali “osztálya” biztosít beginRequest és endRequest eseményeket, melyekre feliratkozhatunk:

  Sys.WebForms.PageRequestManager.getInstance().add_beginRequest(function (sender, args) {
    // Blokkolás itt
  });

  Sys.WebForms.PageRequestManager.getInstance().add_endRequest(function (sender, args) {
    // Blokkolás feloldása itt
  }); 

Ennyi az egész, a kód mehet rögtön a master page tetejére a ScriptManager után, és máris minden oldalon meg fogjuk kapni a Feldolgozás folyamatban… üzenetet aszinkron művelet esetén.

Technorati-címkék: ,,,

Még egyszer az Ajax Library jövőjéről

Közel két hónapja, hogy megírtam, a nagy testvér kikukázta a Microsoft Ajax Library-t és a jQuery mellett tette le a voksát. Azóta megjelent a .NET 4 és ez hozott némi félreértést a köztudatba, amit most megpróbálok kicsit helyre tenni.

Az ASP.NET platform kapcsán igazából 2 Ajaxról beszélhetünk:

  1. Az ASP.NET 4-ben megjelent ASP.NET Ajax – ebben nincsenek benne az igazi új szépségek, a kliens oldali sablonok, kliens oldali adatkötés, sőt még a script loader sem. De van benne minden régi alapozó komponens: osztályok, interfészek, felsorolt típusok. Ez az ASP.NET Ajax elkészült, kiadták (ott feszít a Frameworkben) és támogatott.
  2. Az ASP.NET Ajax .NET-től független, ún. out-of-band kiadása – ezzel lehetett kipróbálni a sablonokat, adatkötést stb. Na ezt nem fejlesztik tovább, ebből nem lesz több verzió, sőt még release sem.

A jQuery csak a 2. esetet “fenyegeti”, bár valójában jót tesz ám neki, csak sokáig tart. Az 1. esetben – legalábbis az ASP.NET WebForms esetén biztosan – nincs tervbe véve, hogy ezeket a funkciókat felváltsa a jQuery.

Ami a két legérdekesebb funkciót, a sablonokat és az adatkötést illeti, már elkezdődött a Microsoft és a jQuery team között az együttműködés. A Microsoft kidolgozott egy módszert a kliens oldali sablonok használatára, amit a community a szokásos eljáráson belül véleményezett, jó sok ötletet és javaslatot küldtek hozzá. A folyamat kezd a vége felé közeledni, az elkészült kód sorsáról (bekerül-e a jQuery cora-ba, hivatalos plug-in lesz-e stb.) pedig mint minden esetben, most is a jQuery team fog dönteni.

A második nagyobb funkció halmaz a kliens oldali adatkötés, amit itt data-linking-nek fognak hívni, mert a “bind” elnevezés már foglalt a jQuery világban. A data-linking valójában adatkötés, méghozzá kétirányú és támogatja a WPF-ből megszokott konvertereket is.

A két funkció természetesen a kliens oldali, deklaratív adatkötés terén fog egymásra találni, ami komoly eredmény lesz. Most ugyan vannak erre egyedi megoldások, de nagyon kellene egy elterjedt, standard megközelítés.

Akit érdekel mindez kód szinten, annak feltétlenül ajánlom Scott Guthrie ide vonatkozó blog bejegyzését.

 

Technorati-címkék: ,,,

Húsvéti kis színes (linkblog)

Hírek a nagyvilágból:

Visual Studio 2010 virtuális gépek: benne laborok, példák és minden, ami a teljes application lifecycle management kipróbálásához kell. Egyelőre a szoftverek Release Candidate változata érhető el, pedig akár már a végleges is lehetne.

BCL csapat a CodePlexen: nem a BCL forráskódja, hanem példák és osztályok, amik nem kerültek bele a Frameworkbe, de hasznosak lehetnek. Szerkeszteni nem lehet, leginkább megosztanak és visszajelzéseket gyűjtenek. Már van fent BigRational, LongPath, PerfMonitor és TraceEvent kód.

ASP.NET WebForms MVP (Model-View-Presenter): Tatham Oddie és Damian Edwards projektje, mellyel az MVC-hez hasonlóan az ASP.NET WebFormsba is bekerülhet a kód szeparálás és a tesztelhetőség. Ugyanerről szóban a 202. Hanselminutes podcastban.

Microsoft Ajax Minifier 4.0: immár nem csak JavaScript, hanem CSS fájlok minimalizálására is képes. Nekem az tetszik benne leginkább, hogy MSBuild task formájában is elérhető, így nagyon könnyen beépíthető a fordítási folyamatba. Erről írtam is korábban.

IIS UrlRewrite Module 2.0: sok újdonság van benne, például egyszerűbb lett a hibakeresés a naplózásnak köszönhetően és van HtmlEncode támogatás is, sőt végre nem csak a bejövő requestre, hanem a kimenő responsra is lehet szabályokat megfogalmazni. Ami messze legjobban tetszik: provider alapú bővíthetőség, példákkal.

patterns & practices Web Client Developer Guidance: a P&P csapat gőzerővel dolgozik, hogy a VS 2010 megjelenésére legyenek részletes ajánlások és referencia implementációk webfejlesztők számára. A béta változat letölthető a CodePlexről.

Orchard alpha: az Orchard projekt célja egy ASP.NET platformon futó, újrafelhasználható komponensekből felépített, nyílt forráskódú CMS rendszer létrehozása közösségi alapokon. A MIX-en kezdtek el róla először nyilvánosan beszélni, már letölthető az alpha verzió és a fejlesztésbe is be lehet szállni!

Feature Builder Power Tool for VS 2010: az Architecture Team által közreadott Visual Studio bővítmény (VSIX) előállító eszköz. A Preview változat letölthető a Visual Studio Gallery-ből, Michael Lehman bemutató videói pedig a Channel9-on nézhetők meg.

 

Technorati-címkék: ,,,

AJAX Library: csak egy maradhat

Az elmúlt években drasztikusan megnőtt az igény a webfejlesztésnél a kliens oldali kódolásra, ám mivel ez alapvetően nem egy fejlesztői kéjélmény, újabb és újabb JavaScript keretrendszerek bukkantak fel. A Microsoft is elkészítette a sajátját Microsoft Ajax Library néven és egész szép eredményeket ért el, különösen az Ajax Control Toolkittel integrálódó új verziókban, írtam is róla eleget. A verseny azonban úgy látszik, véget ért, a favorit pedig a jQuery, amelyet mára a nagyobb webhelyek közül minden harmadik használ. Jogosan merül fel ennek fényében a kérdés: mi lesz veled ASP.NET AJAX?

Azt kell, hogy mondjam, azok számára, akik hozzám hasonlóan elég sok energiát fektettek a Microsoft Ajax Library megismerésébe, a MIX-en napvilágot látott döntés elég elszomorító: KUKA.

A döntés okainak megértéséhez azt kell látni, hogy az ASP.NET platformon kétféle kliens oldali fejlesztő van: az egyik megijed a JavaScript kódtól, a másik nem.

Aki megijed, azt úgy hívja a Microsoft, hogy “ASP.NET WebForms developer” és ők akkor tudnak igazán kliens oldali interaktivitást vinni az oldalba, ha azt egy szerver oldali komponens valósítja meg. Valami, amit be lehet húzni a Toolboxról. Az Ajax Control Toolkit (ACT) őket szolgálja és fogja szolgálni a jövőben is. Van belőlük jó sok, hiszen az ACT-t havonta százezren töltik le, ami nem véletlen, hiszen ezek a szerver oldali vezérlők óriási segítséget jelentenek a fejlesztéskor.

Aki nem ijed meg a kliens oldali kódolástól (“Ajax client developer”), eddig több lehetőség közül választhatott: vagy meztelen JavaScript kódot írt, vagy valamilyen JavaScript keretrendszert használt. A Microsoft eddig azt mondta, hogy a Microsoft Ajax Library az üdvözítő megoldás, például azért, mert van benne a szerver oldali .NET-re emlékeztető kliens oldali osztálykönyvtár, típusok, öröklődés stb. Ráadásul folyamatosan fejlődött is a Microsoft Ajax Library, a 4.0 verzióra durva újdonságokat kapunk: script loader, DataView vezérlő, adatkötés, template-ek stb, sőt nemrég az egész Ajax Control Toolkitet átírták úgy, hogy a Microsoft Ajax Library-t használja.

És ebben a pillanatban, amikor már kezdett igazán ütőssé és vonzóvá válni ez a library, akkor döntöttek úgy Redmondban, hogy a jövőben mégsem a sajátjukat favorizálják, hanem a legmenőbbet, a jQuery-t. A jQuery-t eddig is támogatták, hiszen az ACT-ben lévő vezérlők jQuery-ből is elérhetőek voltak, a jQuery a Microsoft CDN-re is felkerült, sőt az ASP.NET MVC-nek része is lett. Most azonban a MacLeod klán nagy reményű ivadéka önmaga fejét vágta le, hogy végül csak egy maradjon.

Röviden:

  • Szerver oldali fejlesztők számára várhatóan pár havonta lesz új Ajax Control Toolkit mégpedig a CodePlex Foundation kezelésében
  • Az ACT alapjául továbbra is a Microsoft Ajax Library szolgál, de az Ajax Library nem fog tovább fejlődni, legfeljebb a hibákat javítják ki benne.
  • Ha kliens oldali kódot akarsz írni, akkor lehetőleg ne a Microsoft Ajax Library-t használd, hanem a jQuery-t.
  • Ha már használod a Microsoft Ajax Library-t (például az új script loadert vagy a DataView vezérlőt), akkor sincs gond, használhatod továbbra is az ACT részeként. Nem lesz önálló RTM verzió az Ajax Library-ből.
  • Azokra a funkciókra, amikben a Microsoft Ajax Library előrébb járt, mint a jQuery, a Microsoft a standard módon javaslatokat fog benyújtani, hogy bekerüljenek a jQuery-be. A template-ekre ez már megtörtént, van is hozzá kísérleti plugin, majd jön a script loading, data binding stb.
  • A jQuery továbbra is open-source, platform- és gyártó független marad. A Microsoft a többi közreműködőhöz hasonlóan csak javaslatokat tesz, amiket a jQuery csapat vagy elfogad, vagy nem.
  • Bizonyára lesznek Microsoft specifikus részek (pl. WCF RIA Services, WCF Data Services), amik nem fognak bekerülni a jQuery-be, azok várhatóan egy jQuery bővítmény formájában lesznek elérhetőek. A kliens oldali típusrendszer várhatóan megszűnik.
  • Az ASP.NET részeként elérhető Ajaxos vezérlők (pl. UpdatePanel) továbbra is megmaradnak, az új verzióban a .NET 4-be beépített ASP.NET Ajax 4-re épülnek (ami nem épül a jQuery-re).

Hogy érezni lehessen a váltás súlyát:

“Developers on the ASP.NET team are now working full-time to contribute features to the core jQuery library.”

Technorati-címkék: ,,,

ASP.NET AJAX 4: Content Delivery Network és ScriptManager

Korábban már említettem, hogy a Ajax Library-hez tartozó JavaScript fájlokat a Microsoft közzétette a saját Content Delivery Networkjén. Ráadásul nem csak az Ajax Library split script fájljai és a jQuery Library, hanem a System.Web szerelvényben található hagyományos WebForms szkriptek is felkerülnek a CDN-re. Mindez felturbózva a ScriptManager új lehetőségeivel teljesen szabályozhatóvá teszi, hogy pontosan milyen szkript hivatkozások renderelődnek az oldalunkba.

Néhány ScriptManager újdonság és kevésbé ismert funkció:

  • Az EnableCdn tulajdonság állítgatásával egy pillanat át tudjuk állítani az alkalmazásunkat, hogy a Microsoft CDN-ről töltse a JavaScripteket és ne a mi szerverünk sávszélességét terhelje.
  • Az AjaxFrameworkMode tulajdonság Enabled/Explicit/Disabled értékeivel finoman hangolhatjuk, hogy pontosan mely szkriptek töltődjenek be az oldalon.
  • A ScriptReference elem Name, Assembly és Path tulajdonságaival felüldefiniálhatóak a beépített szkriptek, és ez most már a System.Web szerelvényhez tartozó szkriptekre (pl. WebUIValidation.js) is működik.
  • A CompositeScript elem segítségével az egyes ScriptReference elemekben megadott fájlokat a ScriptManager képes egyetlen fájlba összegyúrni és egyetlen HTTP válaszban leküldeni a böngészőnek.
  • A CompositeScript Path tulajdonságának megadhatjuk egy előre létrehozott statikus fájl útvonalát, éppúgy, mint a ScriptReference elemeknek.
  • A ScriptReference elem Assembly attribútumában többé nem kell fully qualified assembly name-et használnunk, elég például annyi, hogy “System.Web”, a Version, Culture és PublicKeyToken értékektől eltekinthetünk. Cserébe a hivatkozott szerelvénynek ott kell lennie a bin mappában, vagy legalább a web.config <assemblies> szekciójában hivatkoznunk kell rá, mert a GAC nem elég egyértelmű.
  • A ScriptManager.ScriptResourceMapping tulajdonságával kódból definiálhatjuk bármelyik szkriptünk Path, DebugPath, CdnPath és CdnDebugPath tulajdonságait.
  • A ScriptManager ScriptMode attribútumában megadhatjuk, hogy a Release szkriptek töltődjenek le a szerverről.
  • A ScriptManager LoadScriptsBeforeUI attribútumát false értékre állítva a szkript hivatkozásokat az oldal aljára helyezhetjük, így jobb felhasználói élmény érhető el.

Jelenleg a következő szkriptek találhatóak a CDN-en:

  • ASP.NET AJAX Library 3.5: az ASP.NET 3.5-ben használatos MicrosoftAjax.js fájl tölthető innen is.
  • Microsoft Ajax Library 4.0 (valószínűleg ez lesz az új branding): jelenleg a novemberi béta érhető el split script és composite script fájlok formájában. A 4.0 RTM után a scriptek valószínűleg a http://ajax.microsoft.com/ajax/4.0 útvonalon lesznek megtalálhatóak és várhatóan ugyanide kerülnek majd a System.Web szerelvényhez tartozó szkriptek is. Érdemes észrevenni, hogy az Ajax Control Toolkit is teljesen átalakult, az új verzió már az Ajax Library-re épül.
  • jQuery 1.3.2: teljes és minimalizált változatban is, már a végleges URL-eken.
  • jQuery Validate 1.6: teljes és minimalizált változatban is, sőt a magyar nyelvű lokalizációval együtt, már a végleges URL-eken.
  • ASP.NET MVC: jelenleg az 1.0, majd a .NET 4 RTM után az ahhoz megjelenő változat fájljai is.

Érdemes megismerkedni ezekkel a lehetőségekkel, Gincsai Gábor barátom AJAX szkriptek összefűzése c. cikke részletesebben is bemutatja egyik-másik kapcsoló használatát.

ASP.NET AJAX 4: JSONP, avagy a Same Origin Policy megkerülése

Aki foglalkozott már AJAX-szal az tudja, hogy privacy okokból az XMLHttpRequest objektummal végzett kérésekre alapértelmezés szerint a böngésző érvényesíti az ún. Same Origin Policy-t, ami azt biztosítja, hogy az AJAX-os kéréseink csak arra a szerverre irányulhassanak, ahonnan az oldal letöltődött. Ez gond, ha nyilvános szolgáltatásokat akarok JavaScriptből elérni, nem is csoda, hogy van szabványos módszer a megkerülésére.

Ha például egy oldal head részébe teszek egy script tag-et és annak src attribútumában egy másik szerverre mutató FQDN-es URL-t adok meg, akkor az adott szkript le tud töltődni a másik szerverről és annak a szervernek a kontextusában fog meghívódni – azaz gyakorlatilag nem vonatkozik rá a Same Origin Policy. A jó hír az, hogy ezt meg lehet tenni dinamikusan is, amikor egy másik szerverre akarok hívni, akkor röptében hozzáadok a DOM-hoz egy script elementet, beállítom a forrását és a böngésző le fogja tölteni onnan a kódot.

Ez már majdnem olyan, mint egy AJAX-os hívás, hiszen bármikor el tudom indítani és ki tudok küldeni vele egy GET-es kérést, az egyetlen probléma vele, hogy nem tudom meg, hogy a szkript mikor töltődött le, illetve azt sem, hogy mi lett a válasz a kérésemre. Ez pedig azért van, mert egy normális AJAX-os hívás visszatérési értéke a következő:

  valami_json_adat

Például a Delicious  JSON API-ját felhasználva lekérhetjük az utolsó 3 postot, ha meghívjuk ezt az URL-t: http://feeds.delicious.com/v2/json?count=2&plain

A válasz pedig ez:

  [{"u":"http://engineeredweb.com/blog/09/12/preloading-images-jquery-and-javascript",
"d":"Preloading Images with jQuery and JavaScript | Engineered Web",
"t":["jquery","images","preload","javascript","plugin","image","preloading","development","plugins","preloader"],
"dt":"2009-12-16T00:00:00Z"},
   {"u":"http://www.allfacebook.com/2009/12/facebook-privacy-new/",
"d":"10 New Privacy Settings Every Facebook User Should Know",
"t":["facebook","privacy","socialmedia","web2.0","howto","security","article","information","social","socialnetworking"],
"dt":"2009-12-16T00:00:00Z"}]

Látszik, hogy ez meztelen JSON, ami nem rossz, de visszatérési értékként használhatatlan, nem tudjuk hol és hogyan feldolgozni. Ha rá tudnánk venni a távoli szolgáltatást, hogy a visszatérési érték ilyen legyen:

  OnComplete( valami_json_adat );

akkor elég lenne a saját oldalunkon belül létrehoznunk az OnComplete nevű functiont, ami automatikusan meghívódna, mikor a távoli szkript letöltődik és paraméterként megkapná a hívás visszatérési értékét. Egészítsük ki az előbbi Delicious URL-t egy plusz paraméterrel: http://feeds.delicious.com/v2/json?count=2&plain&callback=OnComplete

És nézzük meg a választ:

  OnComplete([{"u":"http://engineeredweb.com/blog/09/12/preloading-images-jquery-and-javascript",
"d":"Preloading Images with jQuery and JavaScript | Engineered Web",
"t":["jquery","images","preload","javascript","plugin","image","preloading","development","plugins","preloader"],
"dt":"2009-12-16T00:00:00Z"},
              {"u":"http://www.allfacebook.com/2009/12/facebook-privacy-new/",
"d":"10 New Privacy Settings Every Facebook User Should Know",
"t":["facebook","privacy","socialmedia","web2.0","howto","security","article","information","social","socialnetworking"],
"dt":"2009-12-16T00:00:00Z"}])

Ez már jó nekünk! Látszik, hogy pontosan az előző JSON tömb jön vissza, csak éppen paraméterként átadva a mi OnComplete metódusunknak. A válasz elején tehát van hely egy függvény nevének, ezt hívják padding prefixnek, a szabványt pedig JSON with paddingnek, azaz JSONP-nek.

Ez annyira jól működő és bevált módszer, hogy nagyon sok JSON-os API támogatja mind szerver, mind pedig kliens oldalon. A bevált gyakorlat szerint általában elég a GET-es hívásunk végére egy callback (lehet más is) nevű query string paramétert tennünk és a válasz máris nem JSON, hanem JSONP lesz. Itt egy másik példa: http://twitter.com/status/user_timeline/scottgu.json?count=5&callback=Akarmi

Ami az ASP.NET 4-et illeti, a Microsoft Ajax Library teljes támogatást ad JSONP hívások küldéséhez, ráadásul teljesen transzparensen. A korábban bemutatott DataView-t közvetlenül köthetjük egy távoli URL-hez, automatikusan JSONP-t fog használni. A háttérben ugyanis a Sys.Net.WebServiceProxy osztály dolgozik, aminek van 2 idevágó paramétere:

  • enableJsonp: ha true, akkor a hívás JSONP-vel fog történni. Ezzel gyakorlatilag nem kell foglalkoznunk, mert az osztály automatikusan beállítja, ha nem a saját szerverünkre hívunk vissza.
  • jsonpCallbackParameter: ez annak a query string paraméternek a neve, amiben a távoli szolgáltatás a callback függvény nevét várja. Ennek az alapértéke callback, ha ez jó nekünk, nem kell állítgatnunk.

Az esetek nagy részében ennek a két paraméternek az alapértelmezett működése megfelelő, tehát anélkül, hogy bármit csinálnánk, a hívás automatikusan JSONP-re vált.

A bétában a DataView-hoz kötés bugos és bár van hozzá workaround, inkább a kézi megoldást mutatom meg. A fenti JSON részletekből látszik, hogy a Delicious által visszaadott JSON milyen mezőket tartalmaz, ehhez létrehozhatunk egy DataView-t:

    <ul 
        id="dvResults" 
        class="sys-template" 
        sys:attach="dv">
        <li>
            <b>
                <a sys:href="{{ u }}">{{ d }}</a>
            </b>
            <br /> 
            {{ dt }} 
        </li>
    </ul>

Létrehozhatunk ezen kívül egy szövegdobozt, ahova a Delicious felhasználónevet lehet beírni és egy gombot, amit megnyomva megtörténik az adatok lekérdezése és megjelenítése:

  <input type="text" id="txtUserName" />
  <input type="button" value="Utolsó 5 link lekérése" onclick="getLinks();" />

A getLinks metódusban semmi JSONP specifikus nem látszik, csak meghívunk egy webszolgáltatást:

  function getLinks()
  {
    var userName = $get('txtUserName').value;
    var uri = String.format(http://feeds.delicious.com/v2/json/{0}?count=5&plain, 
encodeURI(userName)); Sys.Net.WebServiceProxy.invoke(uri, null, true, null, onComplete); }

Annyi azért lényeges, hogy az invoke függvény harmadik, useGet paramétert true-ra állítjuk, hogy a kérés ne SOAP, hanem HTTP GET legyen.

Sikeres hívás esetén a WebServiceProxy az általunk készített onComplete metódust fogja meghívni, ami mindössze a manuális adatkötést tartalmazza:

  function onComplete(results)
  {
    $find('dvResults').set_data(results);
  }

A háttérben valójában az alábbi HTTP kérés fog kimenni:

  GET /v2/json/balassy?count=5&plain&callback=Sys._jsonp1 HTTP/1.1
Accept: */*
Accept-Language: en-US,hu-HU;q=0.5
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0)
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Host: feeds.delicious.com

Látható, hogy a WebServiceProxy automatikusan létrehoz egy Sys._jsonp1 (automatikusan sorszámozott) callback metódust, ami azután success esetén meg fogja hívni a mi onComplete callback függvényünket.

A teljes példa kipróbálható és letölthető itt.