XAML kao osnova Microsoftovih internetskih napora

XAML – eXtensible Application Markup Language se, bez pretjerivanja, smatra svetim gralom koji omogućuje nesmetanu kolaboraciju razvojnih inženjera i dizajnera u Microsoftovom svemiru. Radi se o jednoj od tehnologija kojima Microsoft želi pomiriti web developere i dizajnere.

Odmah na početku pojašnjavamo da XAML, sam po sebi, nije taj koji omogućuje sve te krasne prednosti međusobne suradnje – pravi ključ je WPF (Windows Presentation Foundation), a XAML bi onda mogli smatrati sredstvom kroz koje se, dijelom, WPF manifestira.

XAML se često opisuje pojmom markup language – isti atribut nosi i niz drugih opisnih jezika za sučelja poput HTML-a (hypertext markup language), SVG-a (scalable vector graphics) ili XUL-a (XML user interface language). Uspjeh HTML-a kao tipičnog, i vjerojatno najpoznatijeg i najrasprostranjenijeg markup jezika, ide u prilog tvrdnji kako su opisni jezici za sučelja uspješni i da su zajedno s razvojem ukupne platforme (kako za desktop, tako i za web) i sami rasli. XAML je u svojoj suštini nalik XML-u, no XAML nije samo jezik za opisivanje izgleda samoga sučelja. Uporabom XAML-a moguće je definirati i korisničke kontrole, na njima dodavati event handlere koji se, kasnije, povezuju s programskom logikom u code – behind datotekama.

Dakako, kao i gotovo svi opisni jezici, XAML je čitljiv (human readable), što je prednost koju ne treba zanemarivati. Primjerice, prilikom razvoja u Expression Blend 3 okolini, klikom na split view), u gornjem se dijelu zaslona vidi izgled sučelja ,dok se u donjem dijelu vidi jasan i čitljiv XAML kod.

Izražajnost, sadržajnost, proširivost, odvojivost…

Microsoft XAML tržišno se pozicionira kao opisni jezik s velikim brojem prednosti u usporedbi s drugim opisnim jezicima za sučelja. U prvom redu tu je njegova izražajnost – mogućnost da opiše gotovo sve korisničke kontrole koje dolaze u .NET Frameworku (button, toolbar, combo box…), kao i mogućnost da se kroz njega kreiraju i definiraju neke nove korisničke kontrole. Nadalje, osim samih kontrola, tu su i mogućnosti pozicioniranja elemenata sučelja u različitim elementima (canvas, grid, panels) te opisi svakog pojedinog elementa nizom atributa (colors, fonts…).

XAML

Tu priča ne staje – podrška za animacije, 3D objekte (uključujući njihove definicije, teksture, osvjetljenja…) i vektorske oblike (uključujući i free form paths) samo su neke od mogućnosti koje upotpunjuju izražajnost XAML-a.
Drugi element je sadržajnost, a nadovezuje se na izražajnost. Već je rečeno kako XAML opisuje mnogo više od samih vizualnih elemenata sučelja i tako povezuje sebe kao opisni jezik s moćnim WPF-om. Sadržajnost je, s druge strane, najjasnije istaknuta u podršci za stilove (styles), predloške (templates), povezivanje s izvorima podataka (data binding) i animacije.

Definiranje stilova svoj je uzor vjerojatno pronašlo u vezi između CSS-a i HTML-a. U XAML-u, a posve podržano i kroz Blend kao dizajnersko i razvojno okruženje, definiranje stilova predstavlja vrlo učinkovit način odvajanja izgleda pojedinih elemenata sučelja od njegovog sadržaja.

Predloške u XAML-u možemo promatrati kroz dvije perspektive – prva podrazumijeva predloške kontrola (control templates) čija izmjena omogućuje promjenu izgleda pojedinih kontrola bez utjecaja na njihovo temeljno ponašanje i podržane oblike interakcije, dok predlošci za izvore podataka (data templates) omogućuju dizajnerima kreiranje niza vizualnih elemenata za predstavljanje pojedinih izvora ili tipova podataka. Microsoft tu posebno ističe izostanak potrebe da se grade posebno prilagođene kontrole koje bi uparivale izvore podataka s elementima korisničkog sučelja.

Povezivanje s izvorima podataka jedna je od najčešćih operacija koja se danas izvodi prilikom pisanja softvera. Bilo da izrađujete tipičnu poslovnu aplikaciju, RSS čitač ili aplikaciju za POS sustave, povezivanje s izvorima podataka nešto je što ćete u pravilu uvijek raditi. U WPF-u je povezivanje s izvorima podataka sveprisutno i kao takvo se odražava i kroz sam XAML. Expression Blend kao alat izbora vam, primjerice, omogućuje da izradite RSS čitač koji kao izvor podatak koristi neku XAML datoteku praktično bez pisanja linije koda.

I konačno – animacije. WPF dolazi s izuzetno bogatim modelom koji podržava animacije. Same se animacije mogu prikazati i pokretati kroz sam XAML. Gledajući iz šire perspektive, to znači da dizajner može definirati neku animaciju (primjerice da gumb iz plave postane narančaste boje prilikom prijelaza pokazivača miša preko njega) bez ikakva znanja o programiranju. Dakako, ako ga ima  – to ne šteti jer omogućuje čitav niz dodatnih interesantnih scenarija.

Treći element koji karakterizira XAML je proširivost. Ponovno, teško ga je promatrati izvan konteksta dva ranije spomenuta, izražajnosti i sadržajnosti, jer se na njih nadovezuje. Zajednica razvojnih inženjera vrlo jasno ističe kako XAML sam po sebi nije programski jezik nego „.NET jezik za serijalizaciju i inicijalizaciju“. Konkretno, time se, zapravo, želi reći kako XAML može učiniti i više nego samo prikazati već postojeće osobine WPF-a kao platforme. Izrada i predstavljanje novih kontrola, novih animacija kao i gotovo bilo kojeg .NET podržanog objekta samo su neke od mogućnosti.

Ističe se i to kako se XAML može predstaviti kao programski kod prikazan XML-om. U detaljiziranje i raspravu oko ispravnosti tog stajališta svatko se može upustiti samostalno, u svoje slobodno vrijeme…

I posljednja „-ost“ u ovom nizu je odvojivost. XAML donosi onu pravu, punokrvnu odvojenost koda (programske logike) i korisničkog sučelja. Definicije korisničkog sučelja (uključujući sve više navedene elemente poput kontrola, stilova, predložaka, animacija…) nalaze se u .XAML datotekama, dok se programska logika nazali u C# ili VB code-behind datotekama.

Tako, konkretno, dizajner nacrta pravokutnik i uredi njegovo oblikovanje te mu kao event handler za MouseDown pridruži rutinu „MouseClicked“. U tom se trenutku u datoteci  code behind stvara mjesto na kojem razvojni inženjer može napisati kod i implementirati programsku logiku. Sve izmjene koje dizajner radi na sučelju ostaju u XAML datoteci i ne interferiraju s radom razvojnoga inženjera, a sve što razvojni inženjer stvori u datoteci koda ne smeta i ne utječe na izgled korisničkog sučelja.

Naravno, dizajner radi u Expression Studio okruženju, a razvojnom inženjeru će se otvoriti Visual Studio. Međusobno se automatski sinkroniziraju prilikom izmjena i nema konflikata. Tipične formate rješenja i projekata kao i same datoteke koda i XAML potpuno podržavaju i Visual Studio i Expression Studio. Time je postignuto da svaka strana radi ono u čemu je najbolja, da to mogu raditi paralelno (sjećamo se ideje o povećanoj produktivnosti i fleksibilnosti?) i. što je možda najvažnije, nema  potrebe za kompromisima.

Kompromisi odlaze u prošlost

Export?

Zvuči pompozno, ali s pojavom XAML-a, nestaju zidovi između razvojnih inženjera i dizajnera, a time i potreba za manjim ili većim kompromisima s obje strane. Zaista, kompromisi sada ustupaju mjesto suradnji koja može biti vrlo glatka i fluidna. Zadovoljena su sva tri uvjeta s početka priče – od workflowa do alata koji to podržavaju i XAML-a kao medija u sredini koji to katalizira. Osim kompromisa, u prošlost odlazi i jednosmjernost i serijalnost razvoja koji svoje mjesto ustupaju paralelnom, suradničkom modelu rada. Marketinška mašinerija  reći će kako to sada otvara niz novih mogućnosti za rad dizajnera i razvojnih inženjera i jedan sasvim novi dijalog koji može, u konačnici, rezultirati nizom beneficija za obje strane, ali osobito za same korisnike.

Što to znači dizajnerima i razvojnim inženjerima?

Dizajneri će od sada biti, vjerojatno, po prvi put uključeni u same jezgre razvojnih timova postajući time i dijelom rješenja, ali i stječući vrlo jasniju sliku o tome što razvoj jednog softverskog proizvoda uistinu jest. Prije su dizajneri satima crtali prototipe u PhotoShopu, koristili su PowerPoint za izradu modela interakcije, rezali elemente sučelja i spremali ih kao GIF, PNG, JPG, PDF datoteke i onda pokušavali s razvojnim inženjerima svoju prvotnu misao pretočiti u realnost. Naravno, to u pravilu nije bilo sasvim uspješno i moralo se pristajati na kompromise.

Ako su dizajneri zamislili okrugli gumb, a razvojni inženjer se tome usprotivio jer njegovo razvojno okruženje to ne podržava (recimo, to je teško izvedivo uporabom Windows Formsa) moralo je doći do kompromisa. Dakako, i jedna i druga strana su gorljivo zagovarale svoje stajalište – no rezultat je u načelu bio ustupak jedne ili druge strane, što se nužno moralo odraziti na sam izgled i funkcionalnost aplikacije te krajnje iskustvo korisnika kada bi aplikacija došla do njega.

Danas dizajneri ne moraju trošiti svoje vrijeme uvjeravajući razvojne inženjere u ispravnost svojih odluka i vizualnog izražaja i ne moraju dizajnirati s ograničenjem i pitanjem hoće li se taj dizajn i izgled moći realno prenijeti i u konačnoj inačici aplikacije. Nema potrebe za izradom prototipova i raznih Flash ili Director animacija i koncepata. Sve je moguće odmah i izravno raditi u Expression Blendu.

Grafičke elemente je moguće stvarati u Expression Designu i eksportirati izvorno u XAML formatu i time apsolutno čuvati vjernost izgleda. Napokon, to može značiti da dizajneri prvi slože izgled samog sučelja izfravno u Expression Blendu i samo stvore event handlere te na tom projektu razvojni inženjeri samo nastave svoj rad pišući kod i dodajući programsku i poslovnu logiku u datotekama koda.

Iz perspektive razvojnih inženjera također ima nekih izmjena. Dosadašnja uloga (ili zadaća, ovisno o afinitetima), koja je uključivala i dizajniranje korisničkog sučelja, može posve nestati iz opisa posla razvojnih inženjera. To bi u pravilu trebalo rezultirati oslobađanjem više vremena i bolju usredotočenost na pisanje koda i stvaranje još stabilnijih i funkcionalnijih aplikacija, ali, može, djelovati i na ego. Niti dizajneri niti razvojni inženjeri nisu na to imuni. Nažalost, nikakav XAML ili alat tu ne mogu pomoći.

Ono što može pomoći jest međusobno razumijevanje objiju strana i njihovih specifičnih i nadopunjujućih uloga u timu te transparentnost i jasna podjela uloga i poslova. Tehnologija danas postoji, postoji i podrška za nju. Sada je samo potrebno sve te elemente objediniti i konkretizirati. Rezultat ne bi trebao izostati, a od njega bi koristi trebali imati svi – najviše sam korisnik rješenja, što bi i trebala biti misao vodilja u cijelom procesu razvoja softvera.