Visual Studio 2008 nici nu fusese lansat cand tehnologiile promise de aparitia Framework-ului 3.0 au incins comunitatile dezvoltatorilor .NET. Reactia este normala tinand cont ca au fost abordate trei domenii cu impact major in “sufletul” oricarui dezvoltator, domenii care pana acum nu primisera suficienta atentie din partea Microsoft.

   Subiectul articolului de fata este WPF (Windows Presentation Foundation), unul dintre “cei trei crai de la rasarit” care a fost lansat odata cu Framework 3.0 si imbunatatit apoi in Framework 3.5.

   Ideia de baza pe care se sprijina WPF este legata de faptul ca interfata unei aplicatii are un impact foarte mare asupra utilizatorilor dar foarte multe aplicatii profesionale se concentreaza mai degraba asupra functionalitatilor decat asupra perceptiei utilizatorului.
Acest lucru se intampla si datorita faptului ca, de cele mai multe ori, nu exista un designer specializat in proiectarea interfetelor sau, atunci cand acesta exista, el nu poate decat sa deseneze un layout (o poza) folosind un program grafic. 
Aceasta poza trebuie apoi “transpusa” intr-un form de catre programator care se loveste de limitarile impuse de mediul de dezvoltare, limitari despre care designerul nu stie prea multe.

   WPF isi propune sa rezolve aceste probleme oferind unelte puternice care pot fi folosite de catre designeri si dezvoltatori pentru a crea interfete prietenoase, interfete care pot avea continut variat (documente, multimedia, obiecte grafice 2D si 3D, etc.) fara a mai fi limitat la butoane si liste simple.

Ruptura existenta intre designer si dezvoltator este rezolvata prin faptul ca interfata se pastreaza intr-un fisier distinct de tip XAML (eXtensible Application Markup Language). In acest fel designerul, folosind un mediu dedicat designului de interfete (e.g.: WPF Designer care este inclus in Visual Studio 2008 sau Microsoft Expression Blend), poate crea interfete ce se vor salva in fisiere XAML si vor fi folosite in mod direct de catre programator care va scrie doar codul aferent fiecarei actiuni executate de catre utilizator.

Fisierele XAML sunt in format XML si au un set bine definit de elemente (Button, TextBox, Label, etc.), lucru care a oferit posibilitatea si altor “intreprinzatori” de a dezvolta medii pentru design-ul interfetelor.
Un astfel de exemplu ar fi Electric Rain’s ZAM 3D care poate crea elemente tridimensionale pentru interfete XAML.         

   Tehnologiile oferite de Windows Presentation Foundation pot fi folosite in trei moduri diferite:

   1. Aplicatii standalone WPF

Orice aplicatie .NET Framework (3.0 sau 3.5) poate avea o interfata WPF si probabil in curand foarte multe aplicatii vor imbraca aceasta “faţă”.

 

   2. Aplicatii browser XAML (XAML Browser Application: XBAP)

Desi aplicatiile standalone pot fi seducatoare, exista multe situatii in care se doreste ca aplicatia dezvoltata sa ruleze intr-un browser web.Pentru a permite utilizatorului sa aiba acces la interfete complexe cu ajutorul browserului web, WPF pune la dispozitie aplicatiile XBAP.Aplicatiile XBAP folosesc aceleasi clase ca si aplicatiile standalone dar in urma compilarii se vor obtine fisiere cu extensia .xbap.XBAPs ruleaza in interiorul browserului web (Internet Explorer sau Firefox) si sunt intotdeauna incarcate folosind mecanismele ClickOnce pentru a apela ultima versiune a aplicatiei. Procedura de incarcare este transparenta pentru utilizator efectul fiind similar cu cel al incarcarii unei pagini web oarecare.

   3. Documente XPS

Documentele XPS sunt documente cu format fix care sunt definite folosind XAML, iar WPF ofera un control (DocumentViewer) care poate fi folosit pentru vizualizarea lor. 

   Desi cu ajutorul XBAPs se pot dezvolta aplicatii complexe care ruleaza in browser, Microsoft nu se putea opri aici deoarece scopul “ascuns” era sa ofere o portabilitate si o integrare suficient de mare asa incat sa poata concura in mod direct cu platforme consacrate (e.g.: Adobe Flash).
In acest punct Microsoft aduce in scena Silverlight al carui nume de cod este WPF/Everywhere (WPF/E).
Scopul lui Silverlight este de a oferi un subset al capabilitatilor WPF care sa ruleze pe orice platforma.

   Pentru a puncta mai exact diferentele intre Silverlight si XBAPs trebuie spus ca desi aplicatiile XBAP ruleaza in browser, comportamentul lor (la nivel vizual) este asemanator cu cel al aplicatiilor windows. Fisierul cu extensia .xbap este apelat in mod direct din browser si fereastra browserului este ocupata in intregime de catre aplicatia respectiva.In contrast cu aceasta abordare, aplicatiile Silverlight pot fi inglobate in interiorul unor pagini web normale intr-o maniera foarte asemanatoare cu cea a fisierelor flash (flw).
In plus, pentru a rula, aplicatiile XBAP solicita prezenta Framework-ului pe calculatorul pe care ruleaza, pe cand cele Silverlight nu necesita decat instalarea unui plugin in browser.
Acest plugin este disponibil pentru mai multe platforme (Windows, Macintosh, etc.) si ruleaza in diferite browsere (Internet Explorer, Firefox, etc.).

Un exemplu de aplicatie Silverlight bogata in continut multimedia este in imaginea urmatoare:

 

   Microsoft intentioneaza sa faca din Silverlight un cross-platform in cel mai bun sens al cuvantului. (Ca stire de ultima ora poate fi spus faptul ca Microsoft a semnat  un acord cu Nokia intentionand sa ofere plugin-ul Silverlight pentru telefoanele mobile cu sistem de operare Symbian pe platformele S60 si S80.)         

   In comparatia XBAP versus Silverlight trebuie subliniat totusi faptul ca Silverlight nu ofera toate facilitatile aduse de WPF avand, dupa cum am mai precizat, un subset de capabilitati. Un exemplu concludent ar fi faptul ca WPF ofera suport pentru grafica 3D pe cand Silverlight se limiteaza doar la grafica 2D.Dar chiar daca Silverlight poate fi considerat fratele mai mic al lui WPF, el ofera suficient de multe facilitati pentru a permite construirea unei interfete bogate in  continut: grafica 2D, imagini, sunete, video, animatii, text.         

   Pentru a concluziona putem spune ca XBAPs permite dezvoltarea applicatiilor Windows care ruleaza in browser in timp ce Silverlight este conceput pentru a dezvolta Rich Internet Applications care ruleaza pe toate sistemele actuale.

I think it was september 2004 when I had the chance to meet Eric Rudder from Microsoft, Senior Vice President for Server and Tools. He was on a trip in Romania and met some of the Microsofties down here. We could ask questions about future, he spoke us some things about his life. In three words: strong and great personality.
Back then I was finishing a project which involved a rudimentary form of Ajax, in house developed and I was very very bored with the mess of Javascript and DIV's and IE memory problems which affected my application's quality and performance.

I don't remember the first two "proposed directions" I told him, but the third was: I want to be able to run .NET code in the browser. Some people laughed at the proposal, which kind of made me feel somehow unconfortable. Eric pointed out that he knows we already can write .NET in the browser. I wasn't new in the technology so I knew it wasn't true.
We cannot say the actual .NET is a proper solution to run applications in browser. Maybe I was misunderstood, but now we have Scott Guthrie underlning that MS has brought .NET in to the browser through silverlight (March 2008, minute 1:58 please). The technology is not new, and I do not compare it to Flash or other RIA options available right now. The technology has it's roots in X11, where you could run process on one server and display them on any X11 capable device, just more decoupled.

I belive silverlight is the king. If Microsoft will properly suport this platform, this has the chance to become the new base for interacting with the "cloud" as they mention it.
From my humble point of view, MS is on the right track: comunity, comunity, comunity. Continous feedback, open source and continous inovation.

Some sample about XWindows resources here.

I recently performed a survey in order to see the status of the XML user interface definition languages currently available as a viable solution for enterprise applications. As there was no single and straight answer, I shall enumerate here what I found, just for the record. I am searching to see what is the most viable option for a Rich Internet Application and I want to see what the options are. For those who are not comfortable with the subject, writing forms in C#, Java or other OO language is not a viable option, XML seems to be a better way (see HTML for the web). How could the same concept be applied to windows based forms is not clear for now, at lease there's no standard.

There is a site called OPEN XUL Alliance which gathers a lot of informations about the available options for an XML based user interface. I do not want to copy those informations, just enumerate the most important (as I considered)

1. Mozilla XUL
2. Luxor XUL
3. Thinlet
4. MyXAML
5. Xamlon
6. XForms

A quick comment for the above, Mozilla will never be supported by MS, Luxor also. Thinlet and other Java-based must implement something close to MS XAML, otherwise the .NET industry (MS speciffic) will not adopt it. MyXAML is supported my Marc Clifton ans is quite nice, but it is .NET based, I don't see an option for cross platform. Xamlon allows you to write XAML without Vista but again no cross platform. This is a nice option but again it is MS oriented, I saw they released a beta version of Xamlon Web which somehow transforms IL bytecode into SWF files and is able to execute an application in a browser. I did not tried it but seeme doable.

XForms is a standard and that's it, nothing more.

You all heard about XAML which will be provided in WinFX but we all have to wait and for many of us it will even impossible to use. It comes into my mind big corporations which take very long to switch systems, which still have Windows 2000 and are happy with it. If you will develop enterprise software, the choice to couple with the XAML offered by MS is not viable. But let's go further...

Other options we have:

1. Oracle UIX
2. Macromedia Flex
3. Microsoft XAML and WPF/E

UIX is bound to ORACLE and that means big bucks, because you have to buy oracle server and all those oracle tools. From the technological point of view it is somehow portable as it is based on HTML and JavaScript so if you have the bucks you might consider working with it.

I saw Macromedia Flex and it seemed to be a nice option. Let's see the goods and bads:

Goods:

1. It runs in Flash and we all have the flash plugin, it runs in any browser  (compact browsers also ? :) )
2. It comes with full 2d/3d graphic support
3. It is created by the authors of Flash, some guys who know what they are doing for optimisations, future releases, etc. (this is an bad point for all other creators of XUL in flash)
4. It integrates well with Java Serve Side Applications and will also integrate with .NET
5. Comes with a standardised scripting language (ActionScript)

Bads:

1. Is proprietary
2. It requires a server application to generate the SWF files from the XML sources
3. Development environment is not very mature, debugging, support, etc. are questionable. (I didn't see the trial)

XAML from Microsoft will not ship very soon and in order to be widely adopted will take 2-3 years, so I don't see it as a solution, maybe use Xamlon for the time beeing and change to XAML only for the clients which allow it.

What I need:

1. A standardized XML language which can define a rich user interface (like HTML on the web but richer) which could run on 2-3 platforms (Windows, Linux, Max)
2. A good (maybe OO) language for performing simple UI process to be executed on the client (like JavaScript) but more reliable having good comunication skills (WebServices, etc)

Both of them must be open, accessible to everybody.

Why not HTML, because it does not offer the power of windows controls. This is however a problem because most of the people tend to create from an existing OO hierarchy (say WindowsForms) to create a XML version, so it is platform dependent. So we might not see very soon something standard and accepted by all people like HTML was.

Why not JavaScript, because it is not reliable. I worked much with IE from 5.5+ to 6.0 and pushed the limits of Javascript to it's ,limits, HTC components and a lot of tricky stuff. It fails to perform well, crashes the browser, hits 100MB of memory, a pain in the ass when debugging.

A good  XML language for describing UI I did not found, but the language for UI processes might be Python. It's an early guess but look at how you call an webservice in python:

server = SOAPProxy('http://services.xmethods.net:80/soap/servlet/rpcrouter', http_proxy=proxy)
server.getTemp(zipcode='94063')

No class generation, no proxy, just call it. All you need is a good text editor which understands WSDL and autocomplete for WSDL. See also IronPython

I'm still searching...

 

I'm not confident Ajax will have a big future. We all know Ajax has been there for 4 to 5 years ago from the technological point of view. I participeted in the development of a Ajax type of application a couple of years ago and we had to deal with some issues:

1. JavaScript is a pain when you write cross browser code - we decided to code only for IE
2. JavaScript in IE is slow, very slow if you try do perform complex operations on the client. Back then the computers weren't so powerfull so performance was not so spectacular
3. JavaScript in IE crashes the browser from time to time.
4. JavaScript is difficult to write clean code and debug problems
5. Ajax style pages are not compatible with the "back/forward" button of the browser which people are so used to.
6. IE is not a platform for desktop-based applications, it was not designed for that and will not be changed in the near future.
7. Ajax based application have much more network calls than normal ones. See here 

I am not so confident that enterprise application could be based on the Ajax technology as a framework. For sure there will be some gadgets which will mke life easyer but only locally, not as a general concept.

Let's take a look at Yahoo beta, a wonderfull UI, close to what desktop Outlook has, but difficult to work with. It sees slower than the original one, the scrolling in the message list is very difficult, if you have hundread of messages and slow connection then there's no chance.

HTML is good at representing information, pages, links but building a serious UI only with HTML has for now I think is not a good solution. HTML is not for UI, it is for presentation.

Mozilla XUL, XAML or other markup languages are more close to what a UI should look like, but there is no standard for these ones so we'll wait some time before we can use one as a general purpose UI language.

Ajax is cool for now, but the need for a standard UI language is still open.