Monthly Archives: April 2012

jQueryUI Datepicker lokalizálás

A jQueryUI Datepicker minden szempontból annyira praktikus, hogy már szinte minden projektünkben használjuk. Az eredetileg angol nyelven megjelenő naptár vezérlőt nagyon könnyen lehet más nyelvűvé alakítani, mindössze az adott nyelvhez tartozó lokalizációs fájlt kell betöltenünk az oldalunkra, majd át kell kapcsolnunk rá a Datepickert:

$(selector).datepicker($.datepicker.regional['hu']);

De mi van akkor, ha az oldal renderelésekor még nem tudjuk, hogy milyen nyelvre lesz szükségünk? Ilyenkor jöhetnek a dinamikus szkript betöltési módszerek a kb. 1KB-os nyelvi fájlok betöltésére.

Ha sokszor, sokféle nyelven használjuk a dátum vezérlőt, akkor hasznos lehet a kis méretű fájlok külön-külön letöltése helyett egyszerre letölteni az összes nyelv beállításait. Ezen az URL-en található egy ilyen fájl, amiben az összes (?) támogatott nyelv beállításai megtalálhatók:

http://ajax.googleapis.com/ajax/libs/jqueryui/1.8.18/i18n/jquery-ui-i18n.min.js

Ez egy minimalizált fájl, de a mérete még így is 51KB, azonban ha a webszerveren beállítjuk a tömörítést, akkor mindössze 11KB marad.

 

Technorati-címkék: ,,

Hány eleme van egy JavaScript tömbnek az IE szerint?

Az ember JavaScriptben nem fejleszt, hanem debuggol. Például tömbök túlindexelését. Találtam például egy tömböt, ami minden böngészőben 5 elemű, kivéve Internet Explorerben, ahol 6. Szerencsére van az IE-ben Developer Toolbar, persze rögtön megnéztem vele, mi van benne:

js-array-length

Akárhogy is nézem, ez 5 elem, de a length property szerint 6. WTF???

Íme a forráskód:

js-array-source

Tegye fel a kezét, aki látja a hibát!

Szóval a hiba nem a böngészőben van, a szörnyet én alkottam. Igen, azzal a vesszővel, és naná, hogy copy-paste-tel (talán nem is kéne Copy funkció a VS-be, elég lenne a Cut, sok hiba elkerülhető lenne úgy). Azért érdekes, hogy a böngészők többségének meg sem kottyan a programozói bénázás.

 

Technorati-címkék: ,,,

SkyDrive 7GB vagy 25GB

Megjelent a SkyDrive új verziója, amelyről a Building Windows 8 blogon minden lényeges információ megtudható: vannak új alkalmazások telefonra és desktopra is. Az ingyenes tárhely azonban immár nem 25GB, hanem alapból csak 7GB, ami pont egy Dropboxnyival több a Google Drive-nál 🙂

Azonban aki április 22. előtt már használta a SkyDrive-ot, az most ingyenesen kérhet magának 25GB tárhelyet. Így:

Irány a Manage Storage oldal:

skydrive-manage-storage

Ha megjelenik a Free Upgrade! gomb, akkor szerencsénk van, csak nyomjunk rá:

skydrive-upgrade

Ha utána ez jelenik meg, hátradőlhetünk, mert készen vagyunk:

skydrive-upgraded

Az ezzel kapcsolatos FAQ itt olvasható.

 

Technorati-címkék: ,

ClickOnce érdekességek

Összességében szeretem a ClickOnce technológiát, mert jelentősen megkönnyíti a felhasználók életét, ezért is használjuk a VIK-en a záróvizsga jegyzőkönyv program telepítéséhez. Persze nem minden esetben ez a legjobb telepítőcsomag formátum, hiszen a testreszabási lehetőségek korlátozottak, de nekünk éppen megfelel. A héten – fél év után ismét – egy új verziót publikáltam volna a programból, de belefutottam néhány érdekességbe.

Nem lehet publikálni

Az új verziót a következő módon szoktam elkészíteni: Project Properties –> Publish –> Verziószám beállítása –> Publish Wizard, mert így tudom legjobban kézben tartani, hogy mi történik. De most erre ezt az üzenetet kaptam:

Error: Cannot publish because a project failed to build.

Az Output ablakban semmi több, ennyiből kell főznünk. Hát, ha balról nem engedi a ló, hogy felszálljunk rá, próbáljuk jobbról: Solution Explorer –> jobb klikk a projekten –> Publish. Így megy, csodálatos! 🙂

Lejárt a tanúsítvány

Amikor már azt hittem, hogy sínen vagyunk és csak egy Visual Studio bugba sikerült belefutnunk, szembejött az alábbi érdekes hiba:

The signer’s certificate is not valid for signing.

Ejha, ennek a fele sem tréfa, nézzük csak meg azt a tanúsítványt. Irány a Project Properties ablak, azon belül is a Signing (nem a Publish!) fül. Íme az aláíró tanúsítvány:

clickonce-certificate

Igen, ez a Visual Studio által generált önaláírt tanúsítvány, amire nincs mentség, csak kifogások, nem volt más választásunk. Szemmel láthatóan ez valóban lejárt, tehát itt valamit tenni kell. Van ezen az ablakon egy Create Test Certificate gomb, amivel simán generálhatok új tanúsítványt, de annak következményei vannak. Először is jön ez az üzenet:

The application is signed with a different key than the existing application on the server. Do you want to overwrite it?

Amire mondhatjuk, hogy naná, de az MSDN szerint akkor bizony a régi felhasználóink nem fogják megkapni a frissítést. Ez a mi esetünkben semmiképpen sem elfogadható, más megoldás kell. Elvileg .NET 4 esetén ez már nem probléma, mégsem akartam kockáztatni.

Valahogy tehát meg kellene hosszabbítani a létező tanúsítványt, amihez a KB925521 cikkben találunk is útmutatást, egy rakás .cpp kód formájában. Cliff Stanford oldaláról letölthető egy lefordított RenewCert verzió, ami nálam a C runtime library-kre hivatkozva elszállt, de szerencsére Robin Shahan blogjában találtam egy olyan változatot, ami mellett ott állnak a szükséges dll-ek is. Ezzel egy csapásra sikerült meghosszabbítani a korábban használt tanúsítványt és gond nélkül működik a frissítés. 5 évig.

 

SQL mit ír ki

Code review közben akadtam rá az alábbi érdekes mintára, természetesen sokkal bonyolultabb formában. A kérdés a szokásos: mit ír ki?

DECLARE @condition int = 0
DECLARE @new int

IF @condition = 1
BEGIN
    DECLARE @old int = 5
END    

SET @new = @old

SELECT @new

 

 

Technorati-címkék: ,

A sötét felhő*

A Microsoft bejelentette a legújabb szolgáltatását a felhőben, amely Windows Azure Media Services névre hallgat. Az alábbi ábra egészen kiválóan összefoglalja, hogy miről is van szó:

MediaServicesArch

A szolgáltatás egyelőre preview formájában érhető el, amire a mediaservices@microsoft.com e-mail címen keresztül lehet feliratkozni. Bővebb információk a windowsazure.com/media oldalon és a Windows Azure Media DevCenterben olvashatóak.

Aki médiaközpontú alkalmazást szeretne fejleszteni (akár Windows 8 Metro-ra), annak ez a két library sokat segíthet:

Van erre vajon igény ma Magyarországon?

 

* Nincs semmi gondom az Azure-ral, egyszerűen csak így hívták korábban ezt a projektet. 😉

 

Technorati-címkék: ,

April 2012 Update for Visual Studio 11 Beta

Pár napja megjelent az áprilisi frissítés a Visual Studio 11 béta változatához. A frissítés elsősorban stabilitási és teljesítmény problémákat orvosol, többek között kijavították a Razor editoros hibát is. A változásokról egy kicsit részletesebb lista megtalálható a KB2677574 tudásbázis cikkben.

A javítás mindössze 16.7MB és letölthető közvetlenül a Microsoft Download Centerből, illetve akik Ultimate verziót futtatnak, azok számára automatikusan megjelenik egy értesítő buborék a frissítésről:

Visual Studio 11 update értesítés

Az értesítésre kattintva pedig közvetlenül az Extension Manager ablakból telepíthető a frissítés (katt a teljes képért):

Visual Studio 11 update telepítés

Visual Studio 11 Express Beta for Web verziót használók ne keressék ezt a frissítést, automatikusan nem fog megjelenni számukra, ők manuális letöltés után telepíthetik. Későbbi változatokban ezt is orvosolni fogják.

És ha már ott járunk, érdemes bekukkantani az Installed Extensions listába is:

vs11-extensions

Látható, hogy az ASP.NET csapat nagyon sok funkciót bővítmény formájában csomagolt be a Studioba, így Visual Studio és .NET Framework verzióktól függetlenül tudják majd frissíteni őket, ami szerintem nagy királyság!

 

ui: Ha már frissítések: van a VS fejlesztőcsapaton belül egy UX team. Még nem mondhatom el, hogy mit alkottak, de hallják a sírást és dolgoznak ők is.

 

Technorati-címkék:

Alkalmazások bemelegítése IIS 7.5 és 8.0 alatt

Mint minden szoftvernél, webalkalmazások esetén is előfordulhat, hogy az alkalmazásnak induláskor inicializálnia kell magát, adatbázis kapcsolatokat kell felépítenie, cache-t kell feltöltenie, sőt az összes olyan rendszer- és platform komponenst is inicializálnia kell, amelyre ráépül. A .NET keretrendszerre épülő alkalmazások esetén ehhez még hozzájön a just-in-time fordítás, mellyel összességében az alkalmazáshoz érkező első kérés kiszolgálása zavaróan elhúzódhat.

Erre a problémára a hagyományos megoldás az, hogy a felhasználói kéréseket megelőzve mi küldjük be az első kérést a webalkalmazásnak, így mire a valódi felhasználók megérkeznek, már a bemelegített, villámgyors honlappal fognak találkozni. Ezzel a megoldással sajnos legalább három probléma van:

  • Meg kell írnunk a kliens szkriptet, ami HTTP kérésekkel bombázza a webalkalmazásunkat.
  • Gondoskodnunk kell arról, hogy a bemelegítő szkriptünk az alkalmazáskészlet minden indulásakor lefusson.
  • IIS 7.5 előtt a felhasználóktól érkező kérések megelőzhetik a bemelegítő szkriptet (architekturális korlát).

Szerencsére a Windows 7-ben és a Windows Server 2008 R2-ben megjelent IIS 7.5 ezen a területen jelentősen fejlődött. A kulcskérdés az, hogy az alkalmazás minek a hatására kezdi el inicializálni magát?

IIS 6 és 7.0 esetén miután megtörtént az alkalmazáskészlet inicializálása, a rendszer készen áll a kérések fogadására, ám az alkalmazás inicializálását valójában az első kérés beérkezése indítja el (katt a teljes képért):

IIS_7_timeline

Ennek következtében a felhasználónak meg kell várnia nem csak az általa beküldött kérés feldolgozását, hanem még a teljes webalkalmazás inicializálását is, és csak utána kapja meg a választ. A helyzetet súlyosbítja, hogy ha van már egy korábbi futó alkalmazáskészlet, akkor azt a webszerver leállítja, miután az új alkalmazáskészlet inicializálása megtörtént – csakhogy ekkor még az új worker processben a webalkalmazás nem áll készen! A felhasználónak tehát nem csak, hogy sokat kell várakoznia, de még az is feltűnik neki, hogy a korábbi gyors rendszer (az előző alkalmazáskészlet már be volt melegítve) hirtelen egy kérés erejéig jelentősen lelassult.

Az IIS 7.5-ben a fejlesztők változtattak a webszerver architektúráján, így az alkalmazáskészlet inicializálása után automatikusan megtörténhet az alkalmazás inicializálása is:

IIS_75_timeline

Ráadásul itt már igazi átlapolt újraindításról (overlapped recycling) beszélhetünk, mert a régi alkalmazáskészlet leállítása csak az után történik meg, hogy az újban az alkalmazás inicializálása is megtörtént, így az első kérést küldő felhasználó egyáltalán nem fogja észrevenni, hogy valójában egy új worker process dolgozza fel a kérését.

Ez a módszer azonban feltételezi azt, hogy a webszerver tudja, hogyan kell a webalkalmazást inicializálni, ami nyilván nem lehet mindig igaz, hiszen nagyon sokféle rendszer létezik. Valójában ez csak úgy tud működni, ha a webalkalmazás fel van készítve erre a funkcionalitásra, ami természetesen egyelőre nem minden alkalmazásra igaz.

Ha az alkalmazásunk még nincs felkészítve az IIS 7.5 új alkalmazáskészlet architektúrájára, akkor nem marad más választásunk, mint a korábbiakhoz hasonlóan HTTP kérésekkel bemelegíteni az alkalmazást. Itt azonban már van arra lehetőségünk, hogy ezek a bemelegítő kérések még az előtt érjék el az alkalmazást, hogy az előző alkalmazáskészlet leállna vagy a felhasználótól kérések érkeznének. Ráadásul egy új modul segítségével még a kérések beküldéséről sem nekünk kell gondoskodnunk.

Korábban az IIS 7.5-höz a Microsoft kiadott egy Application Warm-Up nevű opcionális bővítményt, ami képes volt a beállított URL-ekre a megfelelő időben beküldeni az inicializáló kéréseket. Ez a modul bár nagyon hasznos volt (főként a SharePoint üzemeltetők imádták), még a béta időszak alatt kiderült róla, hogy nem minden szempontból felel meg a Microsoft hosszútávú terveinek, ezért sajnos levették a honlapról és azóta nem volt kész megoldásunk. Az IIS 8-ban azonban beépítetten megjelent ez a funkció Application Initialization néven:

IIS_AppInit_Install

Szerencsére az IIS 7.5 számára is elérhetővé tették ezt a funkciót opcionális bővítmény formájában, aminek most a Release Candidate változata tölthető le innen:

A telepítés nagyon egyszerű next-next-finish, de utána ne keresgéljünk semmit az IIS Managerben, egyelőre nem tartozik ehhez a modulhoz GUI. A beállításokat vagy a config fájlokban, vagy az IIS Manager Configuration Editor moduljával tehetjük meg.

Első lépésként azt célszerű beállítanunk, hogy az application pool mindig fusson (hiszen a leállási időt akarjuk minimalizálni):

 <add name="MyPool" startMode="AlwaysRunning" ... /> 

Ennek hatására a Windows Process Activation Service (WAS) mindig el fogja indítani az alkalmazáskészletet.

A következő lépés a preloading engedélyezése az alkalmazásnál, szintén az applicationHost.config fájlban:

 <application path="/" applicationPool="MyPool" preloadEnabled="true" ... />


Ez fogja kiváltani az első kérést, ami inicializálja az alkalmazást. Már csak az van hátra, hogy meghatározzuk, mi történjen ennél a kérésnél. Ezt legszebben az alkalmazás web.configjában tehetjük meg a system.webServer szekcióban:

<applicationInitialization remapManagedRequestsTo="Loading.html" 
                           skipManagedModules="true" 
                           doAppInitAfterRestart="true"> 
<
add initializationPage="/Default.aspx" />
</
applicationInitialization>

Az add sorokban több URL-t is felsorolhatunk, ahova  kéréseket fog küldeni a modul az alkalmazás inicializálása alatt. A remapManagedRequestsTo attribútumban pedig egy olyan oldalt adhatunk meg, amit válaszként fog visszaküldeni a rendszer az inicializálás ideje alatt (ez persze csak akkor izgalmas, ha nincs átlapolódás az előző alkalmazáskészlettel).

Ezzel készen is vagyunk. Persze lehet még tovább cifrázni, például küldhetünk vissza többféle várakozó képernyőt is, ha összekapcsoljuk az Application Initialization modult az ingyenesen letölthető URL Rewrite modullal. Ezt az teszi lehetővé, hogy az AppInit modul beállítja az APP_WARMING_UP szerver változó értékét 1-re arra az időre, amíg az inicializálás tart. Ebben a cikkben erre is szerepel példa: http://learn.iis.net/page.aspx/1089/iis-80-application-initialization/

 

Kimaradhat a XAML a Windows 8-ból

ms-days-logoAkik esetleg követnek Facebookon vagy Twitteren már tudhatják, hogy múlt héten Dávid Zoli barátommal Szófiában voltunk.

A bolgár Microsoft múlt héten rendezte meg az MS Days 2012 konferenciát, ami egy meglehetősen komoly rendezvény fejlesztők és üzemeltetők számára. Csak hogy a méreteket érezni lehessen: két nap, 8 párhuzamos szekció, 72 előadás (melynek kb. a fele angolul), 49 előadó (akik közül sokat külföldről reptettek oda) és minderre több, mint 1000 résztvevő.

A szervezés nagyon profi volt, minden egészen flottul ment, talán csak a helyi Lurdy Ház, a Кино Арена volt egy kicsit szűkös ennyi embernek:

Кино Арена

Zolival két előadást tartottunk JavaScriptről, HTML5-ről, MVC-ről és Azure-ról, főként tapasztalatokról és legjobb gyakorlatokról. Akit érdekel, letöltheti az előadásokhoz tartozó prezentációkat és demókat innen. Büszkén jelenthetem, hogy mindkét előadás nagyon népszerű volt, sokkal többen jöttek, mint ahányan a terembe befértek, még a “falakon is lógtak”. Az értékelőlapok összesítését még nem kaptuk meg, de a Twitteren már jött néhány pozitív visszajelzés (kettőnk közül csak én vagyok Twitteren, ezért csak engem emlegetnek, de az előadásokat együtt tartottuk):

ms-bg-twitter1

ms-bg-twitter2

A második előadás után megkeresett minket a Microsoft Research két munkatársa és elmondták, hogy az egyik kiemelt projektjükben kompatibilitási problémák megoldásán dolgoznak és az előadások alapján arra gondoltak, hogy szívesen bevonnának minket is. Konkrétan azon elmélkednek, hogy a XAML egy gigantikus zsákutca, mert már sok “dialektus” van belőle (Silverlight, WPF, Windows Phone, Windows 8) és mindegyik jelentősen eltér a másiktól.

Erről egyébként bárki meggyőződhet: a CODE Magazin atyja, Markus Egger egy nagyon hasznos eszközt tett közzé a CodePlexen XAML Dialect Comparer Tool néven. Az eszköz annyit tud, hogy megadunk neki egy forrás és egy cél XAML változatot, ő pedig végigszántja a névtereket és megmondja, mennyire kompatibilisek egymással. Például ha Silverlight 5-ről Windows 8 Metro-ra akarunk átállni, akkor csak 55,19%-os kompatibilitással számolhatunk. Mindenki eldöntheti, hogy a saját esetében ez mire elég.

XamlComparer

Vissza Bulgáriához. Szóval az MSR-nél két projekten dolgoznak és mivel egy szóval sem mondták, hogy ne beszéljünk róla, elmesélem. Az egyik projekt célja, hogy XAML markupot HTML-re fordítsanak, a másiké pedig, hogy a HTML+JavaScript alkalmazásoknak 100%-osan kompatibilis környezetet biztosítsanak minden platformon. Komolyan elkezdtek azon gondolkodni, hogy a Windows 8 Metro stílusú alkalmazásoknál kínált JavaScript lehetőségek pontosan ugyanabba az irányba viszik a HTML+JS párost, mint a XAML-t: dialektikus zsákutcába. Márpedig ezt a hibát az MS nem akarja még egyszer elkövetni, így nem csoda, hogy Steven Sinofsky-t is komolyan érdeklik ezek a kutatások.

Íme egy példa! Windows 8 Metro stílusú alkalmazásban használhatunk WinJS.UI.ListView vezérlőt, így:

<div id="playeritemtemplate" data-win-control="WinJS.Binding.Template">
    <div data-win-bind="innerText:Name" style="height: 20px;" />
    <img data-win-bind="src:Photo" style="width: 200px; height: 150px;" />
</div>

<div id="PlayerListView" 
    style="height: 185px;" 
    data-win-control="WinJS.UI.ListView"     
    data-win-options="{itemRenderer:playeritemtemplate,
                       layout:{type:WinJS.UI.GridLayout,maxRows:1}}" />

Ez működik kiválóan Windows 8 esetén, de sehol máshol. Arról nem beszélve, hogy a kód elég nehezen olvasható, hiszen a WinJS.UI.ListView vezérlő hozza azt a produktivitást, ami miatt az egészet csináljuk, de fogalmunk sincs, hogy az hogyan működik. Íme egy másik példa, ezúttal egy datepicker:

<div data-win-control="WinJS.UI.DatePicker" 
     data-win-options={maxYear:2020,minYear:2000}" />

Ez is csak Windows 8-on fog bármit is produkálni, miközben dátumválasztásra mindenhol szükség van. Persze vannak tökéletes megoldások: az adatkötés megoldható például KnockoutJS-sel, a dátumválasztás pedig jQueryUI DatePickerrel. Ezek tisztán JavaScript alapú megoldások (beszéltünk is róluk az előadásunkban), tehát nincs platform probléma, feltéve persze, hogy a JavaScript futtatás nem okoz gondot az adott környezetben. Weben mindez természetes, tehát ahol webböngészőt tudunk beágyazni, ott a probléma megoldva. Nézzük sorban:

Silverlight: átfordítjuk a XAML-t HTML-re, a code behindot pedig JavaScriptre és ha a hoszt egy böngésző, akkor máris készen vagyunk. A C#-JavaScript konverzióra Nikhil Kothari Script# projektje szolgáltat megoldást. Ha out-of-browser SL alkalmazásról van szó, akkor sincs nagy gond, hiszen akkor a hoszt az explorer.exe, ami szintén beépítetten támogatja a HTML-t és a JavaScriptet (mindenki emlékszik még a böngésző beépítése körüli jogi hercehurcára). Ez egyben a SL jövője körüli kérdést is megoldja.

WPF: csakúgy mint SL-nél, itt is átfordítjuk a XAML-t HTML-re, a code behindot pedig JS-re, és mivel a hoszt itt is az explorer.exe, futni is fog vidáman. Itt már gyakrabban jöhet elő egy olyan nehézség, ami SL5-nél is, konkrétan a P/Invoke, ez ugyanis kimutat a .NET runtime adta környezetből. Erre még nincs teljeskörű megoldás, egyelőre ott tartunk, hogy aki P/Invoke-ra épít, annak valószínűleg kevésbé fontos a hordozhatóság, de ez még nem kielégítő válasz.

Windows Phone: biztos hallottátok már azt a pletykát, hogy a Windows Phone 8-nál cserélni fogják a kernelt, ami már a Windows 8-ra fog épülni. Ezt egyelőre sem megerősíteni, sem cáfolni nem tudom (ugye értitek Kacsintó arc), a mi szempontunkból csak az a lényeg, hogy ez lesz a legkevésbé fájdalommentes. Ami a Windows Phone 7-et illeti, ott szóba se jöhet egy kernel szintű módosítás, ezért valószínűleg egy runtime réteg fog bekerülni valamelyik frissítésbe, ami gyakorlatilag egy transzparens böngésző lesz a HTML alapú alkalmazások futtatására.

Windows 8: ez a legrizikósabb terület, ugyanis pont itt reklámozta az MS legjobban az új HTML lehetőségeket és most ebből kellene visszalépni a helyes útra, ami persze egy marketing öngyilkosság lenne. Bár erre bármikor lehet azt mondani, hogy eddig csak “preview” változatok láttak napvilágot, ami magában hordozta a változtatás lehetőségeit, és hogy csak az a fontos, hogy a végeredmény hosszú távon jó legyen. A Microsoft Research-ös srácokkal arról beszélgettünk, hogy Sinofsky képes lenne szembemenni a cégen belüli marketing gépezettel a profi végeredmény érdekében.

Felmerülhet persze még kérdésként a sokféle “form factor”, azaz a cél eszközök különböző mérete. Hogyan fognak megjelenni az alkalmazásaink egy kicsi telefonon vagy egy nagyobb monitor képernyőjén? Ezzel kapcsolatban szerencsére pont a Windows 8 miatt már kitalálták a megoldást, érdemes elolvasni Nacsa Sándor idevágó Standards-based adaptive layouts in Windows 8 (and IE10) című írását.

layout

Szintén érdekes problémakör az adattárolás kérdése. Itt az a szerencse, hogy a sok XAML környezet közül már a legkisebb is hozza a közös nevezőt: a Mango óta Windows Phone-on is lehet SQL Compact Editiont használni. Ha pedig külső SQL Serverre van szükség, akkor pedig maradnak a HTTP alapú REST-es API-k az adatbázis elérésére.

Mindezek a projektek gyönyörűen haladnak az MSR-nél, vannak működő megoldásaik nem csak egyszerű, hanem összetettebb alkalmazásokra is. Az igazi probléma az időzítés. Az MSR nem elég nagy ahhoz, hogy az igazi bevételt termelő Windows gépezetet visszatartsa, márpedig ha a Windows 8 megjelenik a Consumer Preview-ban található XAML és a HTML lehetőségekkel, akkor már nincs visszaút, az MS végérvényesen belezöttyen a kátyúba, ahonnan évekig nem mászhat ki (lásd VB6 és ASP támogatás Windows 8-on).

Ennek a meccsnek két eredménye lehet:

1. Marad a mostani felállás, amivel útjára indítják a Windows 8-at mint egy gigantikus kísérletet, és az esetleges problémákat, zsákutcákat majd a Windows 9-ben kijavítják. Ebben az esetben a történelem a Vista-Windows 7 párost ismételné.

2. Sinofsky a sarkára áll és azt mondja, hogy tiszta szerencse, hogy időben észbe kaptunk, szorítsuk egy kicsit háttérbe a saját érdekeinket és adjunk ki egy olyan Windows 8 verziót, ami tényleg hosszú távon jó irányba mutat, hiszen operációs rendszert nem cserélnek sűrűn sem a végfelhasználók, sem a cégek.

Sinofsky már letett valamit az asztalra, és én arra tippelek, hogy elfogadnák az érvelését, bár ez nagy érvágás lenne a Microsoftnak. Ebben az esetben ugyanis jelentősen csúszna a Windows 8 kiadása (az idén biztosan nem lenne belőle semmi), hozzá kellene igazítani az eddig elkészült alkalmazásokat, fejlesztőeszközöket, mindent. Viszont arra is nagyon jó esély van, hogy a végeredmény nagyon jó termék lenne, amivel az MS tiszteletet érdemelhetne ki, ami persze végül a bevételi oldalon is éreztetné a hatását. Így nem meglepő, hogy jelenleg ez a valószínűbb lehetőség.

De mi lesz a fejlesztőkkel ebben az esetben? A XAML halála a WPF és a Silverlight bizonytalan jövője körüli homályos információk óta egyre valószínűbb. A XAML diverzitása a saját halálát okozza, miközben lényegében semmi előnyt nem hordoz a HTML-hez képest, hiszen csak címke parszolásról van szó. Elég csak az ASP.NET MVC 4-ben lévő Razor parserre gondolni és máris tisztán látszik, hogy a HTML alapú megoldások egyszerűen jobbak. (Egyébként a Razor parser is bekerült ebbe a projektbe) Nincs értelme fenntartani egy olyan szintaktikát, ami megosztja a fejlesztői tábort, miközben van egy olyan alternatíva, ami inkább újabb fejlesztőket hozna a Windows platformra.

Ti örülnétek, ha a XAML halála miatt csúszna a Windows 8 kiadása?

 

 

UPDATE: Fontos kiegészítés a fentiekhez: http://bit.ly/xamltohtml

 

Technorati-címkék: ,,,,