Weblabor

WPF/E

A WPF, vagyis a vadonatúj, vektoros, D3D alapú Windows UI technológia megjelenése hajnalán óhatatlanul felmerült a fejlesztőkben, hogy milyen jó lenne, ha az XAML mint XML alapú felület és interakció leírónyelv alkalmazható lenne a szintén XML alapú XHTML leváltására.

A WPF/XAML az XHTML-hez hasonlóan egy XML dialektussal, deklaratívan írja le a felület elemeket. A különbség mindössze az, hogy mind a stilizáció (~CSS) mind pedig a felület működéséhez szükséges interakció (~JavaScript, ~CSS :hover) definícióját is megvalósítja. A stilizáció az XAML kontextusában a Style, Template és DataTemplate elemek, az interakció pedig a Binding és a Command elemek.

Az alapötlet az, hogy egy felhasználói felület működésének és megjelenésének minden mozdulatát le lehessen írni XAML nyelven, ami XML lévén mind a humán, mind pedig a tervezőeszköz számára könnyen emészthető információt biztosít. Ennek eredményeként sikerült elérni, hogy a fejlesztők (kódlogika) és a designerek (UX) munkája elválasztható legyen, és ne függjön egymástól olyan mértékben, ahogy azt más technológiáktól megszoktuk.

A WPF első kiadásában azonban a „webesítés” megoldása mindössze abban merült ki, hogy lehetőség volt olyan WPF alkalmazásokat fejleszteni, amik böngészőben futnak (IE, Firefox), azonban ehhez Windows-ra volt szükség, telepített .NET 3.0-val (XAML Browser Applictaion). Ekkor azonban elkezdtek szállingózni a hírek egy WPF/E (WPF Everywhere) kódnevű fejlesztésről, ami megjelenésekor a WPF „kistestvére” kívánt lenni, egy teljesen keresztplatformos, Flash-szerű böngésző plugin formájában, a „nagytestvér” alapvető szolgáltatásainak biztosításával. Ezen kitűzött célok eléréséhez kerek 3 évre volt szükség.

Silverlight 1.0

Egyszer csak kijelentették „odafent”, hogy a WPF/E mától Silverlight, és kiadtak egy Silverlight 1.0-nak csúfolt valamit. Egy WPF részhalmazt ugye mindenki úgy képzel el, hogy C#-ban, VB.NET-ben vagy bármilyen támogatott .NET nyelven programozza hozzá a logikát és írja a saját vezérlőit. Ehelyett azonban az első verzió teljesen JavaScript alapú volt, mindamellett az XAML készlet is harmatosabb volt annál, hogy butított WPF XAML-nek lehessen nevezni.

Gyakorlatilag minden hiányzott, ami miatt a WPF-et szerettük, még a WPF alapvető layout rendszere sem működött. Az egyetlen igazán használható rész a media streaming alrendszer volt, illetve a vektoros grafikai elemeket lehetett használni alakzatok, designelemek rajzolására az oldalainkon.

Ennek ellenére már ebben az időben is készült pár igen érdekes Silverlight alkalmazás, de ezek száma még jó sokáig nem növekedett.

Silverlight 1.1

A verzió kiadásának egyetlen oka az volt, hogy lássuk, Redmond malmai őrölnek; a fiúk valóban dolgoznak az eredeti elképzelés megvalósításán. Ebben a változatban megjelent a mini CLR, végre volt lehetőség C#-ban fejleszteni a logikát és a vezérlőket. Sajnos ettől maga a grafikus motor még mindig az 1.0-ban kiadott szegényes megvalósítást tartalmazta, se a WPF layout, styling és templating rendszere, sem pedig a vezérlőkészlete nem került implementálásra.

Silverlight 2.0

Az első WPF/E.

• Megvalósításra került a WPF-ből ismert stílusrendszer. Megjelentek az adatkötések. Lehetőségünk volt adat és vezérlősablonokat definiálni a WPF-ben megszokott módon.
• A WPF gazdag vezérlőkészlete is implementálásra került. Az általánosan használt input vezérlőkön kívül (TextBox, ComboBox stb.) a főbb WPF-es layout vezérlőkhöz is hozzáférhettünk a verzióban.
• A szerverrel való kommunikáció is sokat fejlődött. Végre rendelkezésünkre állt a WCF (Windows Communication Foundation) és a WebClient platform a weben használatos összes kommunikációs technológia támogatására (REST, SOAP, POX, JSON, RSS) továbbá a socket alapú kommunikáció támogatása is megvalósult.
• Végre megjelent a Silverlightban a .NET Framework BCL (Base Class Library) összes osztálya, így nem volt akadálya a kliensen való C#/VB.NET alapú logika és vezérlőfejlesztésnek.

Természetesen a Silverlight még nagyon-nagyon távol volt a megszokott WPF és .NET Framework lehetőségektől.

Azonban a 2.0 megjelenésével végre kikristályosodott az az irány, amit a technológia megcélzott magának. Rengeteg helyen lehet olvasni a neten Silverlight és Flash összehasonlítást, viszont ezek egyike sem mérvadó; homlokegyenest más dologról van itt szó, mint amit a Flash képvisel. A Silverlight célja elsősorban nem a szemkápráztató grafikai trükkök bemutatása, hanem Line of Business webalkalmazások fejlesztése. Tehát egy online banki rendszer felülete sokkal inkább a Silverlight profilja, mint a Döbrögi Zrt. aktuális reklámkampányának a 15 dimenziós, „csili-vili” weboldalának prezentációja.

Ebben az időszakban lett világos az is, hogy a Silverlight „hivatalosan” csak Windows és Mac platformokon lesz támogatott. Az előzetes tervekkel ellentétben a Linux változat kidolgozását a Novel által felügyelt, nyílt forráskódú Mono platform fogja megvalósítani. A projekt neve: Moonlight.

Silverlight 3.0

A verzió célja egyértelműen a 2.0 gyatyába rázása.

• Tovább bővültek média platform szolgáltatásai: H.264, Smooth Streaming, HD minőség, DRM, 3rd Party kodekek.
• Rengeteget fejlesztettek a grafikus motoron. A plugin képes kihasználni a grafikus kártya hardveres gyorsítását, végre hozzáférhettünk a Bitmapek pixeljeihez, megjelent az első fecske a Silverlight jövőbeni 3D támogatása hírnökeként (3D Planes), saját pixel shader effekteket írhattunk.
• Az új verzió beépített támogatást tartalmazott a felület témákhoz, továbbá olyan grafikai és interakciós lehetőségek jelentek meg, amiket abban az időben még a WPF sem támogatott (Visual States, Behaviors), pedig roppant egyszerűvé tette a designerek számara a felület-interakciók tervezését – programozói segítség nélkül!
• Végre tudtunk Silverlight alkalmazást futtatni a böngészőn kívül is (Out-of-Browser Support).
• A 3.0-s verzióban több mint 60 előre elkészített vezérlő állt rendelkezésünkre, és ezek forráskódját is elérhetővé tették.
• A Silverlight alkalmazáson belüli navigációhoz is megjelent a támogatás (Deep Linking, Multi-page Application, SEO).
• Az adatkötés ebben a verzióban egyre jobban elkezdett hasonlítani a WPF-ben megszokotthoz, azonban a Command engine még mindig hiányzott.
• Az adatmenedzsment támogatására új vezérlőt vetettek be (DataForm), ami a deklarált metaadatok alapján önműködően építi fel a felületet és validálja az adatokat.

Sajnos még rengeteg olyan alapvető dolog hiányzott, ami egyenértékűvé tette volna a Silverlightot a WCF-fel prezentációs platformként, de ennek ellenére rengeteg olyan technológia és vezérlő jelent meg a verzióban, amiről a WPF fejlesztők ebben az időben (sőt, ma is) csak álmodhattak. Ami nagyon hiányzott: RichText támogatás, nyomtatás, Command engine.

A Silverligt, mint LOB platform, legfőbb alaptechnológiájának előzetes verziója is ebben az időszakban került kiadásra, ez pedig a WCF RIA Services. Dióhéjban arról van szó, hogy a szerveroldali adatok és funkciók kliensoldalról való elérése a WCF RIA Services felhasználásával nem kíván különösebb programozói munkát, gyakorlatilag az egész csak deklarációkból és konfigurációból áll, a platform automatikusan intézi a többit: adatlekérés (LINQ), adatmenedzsment, adatmező-validáció és szerveroldali metódushívás. Ezek kliensoldali megjelenítésének és kezelésének eszköze a vadonatúj DataForm vezérlő és a DomainDataSource (lásd a WCF RIA Services oldalán lévő videókat és cikkeket).

Silverlight 4.0 – A Silverlight „felnőtt kora”

Ebben a verzióban valósult meg az eredeti elképzelés (majdnem) maradéktalanul.

• A legfontosabb dolog, hogy végre kapunk működő Visual Studio 2010 támogatást a Silverlight 4.0 alkalmazások fejlesztésére (ez eddig csak jelzésszinten működött).
• Végre van Command támogatás, így a Silverlight 4.0 alkalmassá vált a MVVM tervezési minta implementálására (erről később).
• Az adatkötésben is újabb, a WPF-ben már megszokott, lehetőségeket vezettek be.
• Managed Extensibility Framework – a kompozit alaklamazásfejlesztés támogatására.
• Az Out-of-Browser támogatás tovább fejlődött, a 4.0-val már szinte teljes értékű desktop alkalmazásokat lehet fejleszteni Silverlight 4.0 alapokon.
• Tovább gazdagodott a vezérlőkészlet, végre van RichText editor, és az új Silverlight támogatja a nyomtatást is.
• Rengeteget optimalizáltak a sebességen, egy 4.0-s alkalmazás 200%-kal gyorsabban indul mint egy 3.0-s.
• Végül, de nem utolsó sorban: A WCF RIA Services 1.0, vagyis RTM státuszba lépett, a szerveroldalon immár .NET 4.0-s lehetőségekkel.

A további lehetőségek elolvashatók a Silverlight 4.0 Whitepaperben. Ebben a dokumentumban rengeteg példakód található, mindenkinek ajánlom az áttekintését, úgy talán világosabbá válik, hogy mi az egész XAML és LOB koncepció lényege, és ezt hogyan valósították meg a redmondiak.

MVVM

Sokat beszélnek .NET körökben manapság az MVVM tervezési mintáról. A Silverlight 4.0 előző változatokban ezt a mintát csak ordenáré nagy hackelések és megalkuvások árán lehetett implementálni, és ezek miatt maga a minta olyan mértékben sérült, hogy már nem lehetett MVVM-ről beszélni a végén. Miről is van szó?

Nagyobb üzleti alkalmazások fejlesztésénél, főleg, ahol több ember dolgozik ugyanazon a projekten, nem vezet célra az a módszer, hogy a kódlogikát közvetlenül a felhasználói felület űrlapjainak és vezérlőinek eseménykezelőibe írjuk, mert egy idő után az egész teljesen átláthatatlan és karbantarthatatlan lesz. Ki kellett hát dolgozni a „spagetti” helyett egy olyan szoftvertervezési ajánlást, aminek szigorú betartása esetén a kód átláthatósága, karbantarthatósága és tesztelhetősége implicit módon előáll.

A legismertebb ilyen minták az MVC (Model–View–Controller) és az MVP (Model–View–Presenter). Nem mennék bele ezek tárgyalásába. A lényegük az, hogy ezen minták alkalmazása esetén a kóder–designer munkafolyamat elkülönítése nincs megvalósítva. A View réteg működésre bírásához is programozásra van szükség, nincs az az eszköz, ami a designerek rendelkezésére állna, ahol a teljes felület megjelenítését és az interakciók megtervezését is lehetővé tenné, ez utóbbihoz programozni kell.

Ez általában két módon zajlik, ha webes fejlesztésről van szó. Szigorú MVC mintánál a designer megtervezi a sitebuildet, ami általában egy statikus HTML+CSS fájlhalmaz. Ezt megfogja a kóder, és az adott platform lehetőségei segítségével dinamikus elemeket „megmozdítja”, tipikusan szerveroldalról renderelt HTML kód segítségével. Az MVP mintáknál, ahol a prezentációért felelős kód egy szinttel feljebb ül a logikában, a sitebuilder a HTML+CSS kódon kívül az interakcióért felelős prezentációs logikát is elkészíti JavaScriptben, ebben az esetben a szerveroldali kód általában a csak Model réteget tartalmazza. Viszont így a designernek érteni kell a kódoláshoz is, nincs leválasztva a kódolás a designtól. (Ezért van az, hogy ma egy webdesigner legfeljebb PSD-ket gyárt, a sitebuilder meg inkább kóder, ahelyett, hogy a designer feladata lenne az egész UI megvalósítása mindenestül.)

A Model–View–ViewModel minta célja a kód átláthatóság, karbantarthatóság és tesztelhetőség biztosítása mellett a kóder–designer munkafolyamat szétválasztásának tökéletes megvalósítása is. Az elképzelés kulcsa az XAML deklaratív jellegéből adódik. A kóder ennél a mintánál a Model rétegen kívül a ViewModel kialakításáért felel. A ViewModel nem más, mint a prezentálandó adatnak vagy logikának egy a megjelenítéstől független, „absztrakt” megfogalmazása. A View XAML segítségével írja le a ViewModel és az interakció megjelenítését, és mivel a XAML deklaratív, nem kell kódolni hozzá, és a megfelelő eszközzel programozói tudás nélkül is szerkeszthető (Expression Blend). Ezért egyrészt megvalósul a designer–fejlesztő munkafolyamat különválasztása, másrészt egy a kódoláshoz nem értő designer is meg tudja tervezni az összes prezentáció közbeni interakciót: animációkat, vizuális státuszokat, értesítéséket, gyakorlatilag minden a user számára megjelenő elemet.

Végszó

A Silverlight 4.0 segítségével végre megvalósultak a a WPF/E bejelentésekor kitűzött célok, semmi akadálya sincs annak, hogy webes üzleti alkalmazások fejlesztésébe fogjunk vele. Ennek ellenére a fejlett média képességek, illetve az egyre fejlődő grafikai, 3D-s képességek eredményeként a Silverlight 4.0 olyan online megoldások platformjaként is szóba jöhet, ahol a felhasználó elkápráztatása vagy a szórakozásának biztosítása a célunk.