Somebody explain the magic of XAML to me

Okay, I'll admit it, I haven't really worked much with DirectX (although I have done some OpenGL work and 3-D on my own the hard way). But why do I feel like I am missing something or another about the "power of XAML"?  I understand the basic language and all, but for all the demos I have looked at it, I keep thinking it is just another 3-D modelling language/presentation system with a different syntax.  

Is it the issue of separating the presentation layer from the "code" or something?

Well do you know how the DOM (document object model) and javascript make it easy to code front-ends as web pages? Rather than writing tons of complex code in a Paint event handler to render the page and workout out exactly what to do for every mouse and keyboard event, you just spew out a load of HTML and attach event code to any elements you're interested in. When you want to change something on the page you just get the object the represents the element you want to change and you alter some properties. CSS even allows you to style things declaratively and with pseudo-elements it even gives a little bit of declarative control over behaviour.

Anway... Avalon does that for 3D. Rather than writing a huge long routine to paint the scene you just define the scene in XML code and when you want to change things you alter some properties. No, it's not particularly mind-blowing and I'm sure there are plenty of libraries out there already that offer this kind of rendering from an object-model faciity. What makes Avalon worthwhile is that it's integrated into a 2D framework that everyone is expected to use in future. It will become far more common to add 3D stuff to user interfaces that would otherwise be just 2D because the hassle of detecting hardware capabilities, managing texture resources and the myriad of other things that weren't worth it before for your average app are now taken care of by the framework - you just take care of the content.

As its name implies, XAML is an Application Mark-up Language. Spinning 3D gadgets is just one aspect of XAML -- simply through the fact that you can control the Avalon via XAML. But first & foremost, XAML is a language to create applications.

Think of a full-blown, desktop .Net application. XAML is one step up from that. A XAML "compiler" consumes XAML and create for you that full-blown, desktop .Net application.

Why create XAML in the first place if you can download & run .Net assembly off the net like ClickOnce? I'm guessing flexibility. That extra step of indirection allows your computer to interpret that <Button /> tag to whatever is appropriate for your platform. Although, currently, a decently complicate XAML application can only be executed on Vista.

There's rumor of a WPF/E, a subset of Avalon functionalities that can run on FireFox and Macs, so maybe you'll have XAML/E. A flavor of XAML that can be ran on FireFox & Macs.

Or maybe this is MS's attempt to "win the web". If Vista becomes wildly successful, XAML could be the next HTML.

It's a step up from the Win32 world. Everything is vector based. Scale a button to 1000% its original size and it's still crisp.
Not only that, but you are no longer held back by the traditional Win32 API. Want a button with an image? Easy. Want a button with a ComboBox inside (sounds silly, I know). Easy.
Finally, you have to look at the ease of styling. Ever tried to get a Button to look exactly how you wanted it using WinForms? You're lucky if you can change the border color.
What I like about Avalon is it changes the way designers make applications. Instead of picking controls for what they look like, you pick controls for what you want the specific functionality to be. If you think "I want a control that allows the user to click and it returns to its original state". Ok, you use a Button. "I want users to be able to choose one thing from many options. Ok, you use Radio Buttons. "I want to display hieararchial data". Use a TreeView. Style it how you want it.
I just also have to add, the power of Avalon's databinding is something that must be experienced. It's a huge leap for any .NET developer (and I'll be bold enough to say ANY developer).

Is the xaml actually compiled? Or is it just a resource within the exe thats read during runtime?

a XAML app is just an XML file on a Server Somewhere. AML file Browser compiler ratings's?? ; -0 EXE curt "NET ASSMBLY

jsrfc58 wrote:

Thanks for the replies...this helps.  But your diagram is throwing me off.  I thought XAML was going to be for more than web apps...? Sort of like separating the presentation layer from the lower level API code.  Maybe I'm confusing the different products I've seen.

I don't have any of the current betas installed for anything at home because I only have one machine, and I depend on it too much for other projects.  I suppose eventually I'll get another box and put beta stuff on it, but probably not anytime soon....thus the "potential future consumer confusion".

Edit: Of course, this helps too... http://en.wikipedia.org/wiki/XAML

It is for the windows desktop environment as well, though the code is referenced to in the XAML file and the designing is all pretty much done there.

The browser (in his example) passes the XAML code to the server which compiles it using the .net framework and then returns the result. Similar is done in the windows desk. environment. (Except the code is compiled locally).

- Steve

jsrfc58 wrote:

Thanks for the replies...this helps.  But your diagram is throwing me off.  I thought XAML was going to be for more than web apps...? Sort of like separating the presentation layer from the lower level API code.  Maybe I'm confusing the different products I've seen.

If you replace the browser with the desktop, the process is similar. A XAML app could reside locally also.

In regards to the layer seperation, this is similar to what's happening w/ ASP.net apps -- where you have a file w/ the layout & another file w/ the code. It's all in the XAML "compiler" where it's flexible enough to create an app from multiple files.

Steve411 wrote:

The browser (in his example) passes the XAML code to the server which compiles it using the .net framework and then returns the result.

Actually everything from the browser downward is on your machine. All the server does is to dish up the XAML code. Think about what your computer does currently with HTML & Javascript. Rendering, compilation, & execution is all done on your machine.

Minh wrote:

Steve411 wrote: The browser (in his example) passes the XAML code to the server which compiles it using the .net framework and then returns the result.

Actually everything from the browser downward is on your machine. All the server does is to dish up the XAML code. Think about what your computer does currently with HTML & Javascript. Rendering, compilation, & execution is all done on your machine.

Well, think about server side for a second. If it is downloaded to the PC locally then why is it "server side"?

Steve411 wrote:

Well, think about server side for a second. If it is downloaded to the PC locally then why is it "server side"?

I'm not sure what you mean by "server side." But once running, the app can make use of your machine's networking services (Indigo, etc...) to connect back to the server for data & such. But I'm pretty sure the server (that serves the XAML code) does not create that .net assembly.

Minh wrote:

Steve411 wrote: Well, think about server side for a second. If it is downloaded to the PC locally then why is it "server side"?

I'm not sure what you mean by "server side." But once running, the app can make use of your machine's networking services (Indigo, etc...) to connect back to the server for data & such. But I'm pretty sure the server (that serves the XAML code) does not create that .net assembly.

I studied XAML and got to work with it at an MSDN event here a few months ago with a fully powered VS1 beta. The presentor told us that "XAML" was server-side. Meaning that it executed on the server end and the client (local pc) only executed the post and get headers. (When running in browser)

They must of mistaken that for something else, then.
- Steve

Steve411 wrote:

They must of mistaken that for something else, then.

Possible.

If you're developing a WPF (Avalon) app from within Visual Studio then the XAML file represents a part of a class.  The other part is written in whatever .NET language you like.  They both get compiled together to create the EXE so for most WPF apps you aren't going to see a ton of .xaml files running around on a client machine.  In the end the EXE has the same IL code as if you'd written the whole thing in code, the XAML just lets you express it in a different way while you're developing. 

You seem to be mixing up two things WPF != XAML.

XAML is just a object serialisation language allowing you to create and expose complex UIs through an XML based language.

WPF is where all the power is. A GPU assisted UI toolkit. All vector 2D and 3D where video can be manipulated as easily as images, what's not to love?

Then combine that with the rest of WinFX including Indigo, voice and other stuff I can't even think of right now means the next gen platform is gonna yield some great applications.

andokai wrote:

Then combine that with the rest of WinFX including Indigo, voice and other stuff I can't even think of right now means the next gen platform is gonna yield some great applications.

Applications such as "Channel9; Desktop Edition".

- Steve

Being a designer, I see great value to XMAL Code. (Yeah, thats right.. I'm a designer, I won't bite I promise)
One thing that is nice about XAML is that it integrates the workflow of the Designer and the Programmer.

For example, now when I mock up an interface in Acrylic I don't have to chop it up into little pieces and then have the programmers stitch it back together. I can simply create a mock interface and then the programmer can grab the XAML code (aka my mock interface design) and code behind it. No chopping up images and putting them back together again. Imagine the workflow, MUCH FASTER and more effecient. Also, this eliminates development time for programmers creating the front end of an application, the designer can do it now and the programmer won't have to be concerned with ergonomics, 'look and feel'.

Another nice benefit is that designers will have the ability to create additional functionality to applications, such as a splitter, or simple button functions, or visual interactivity. Another thing that XAML is able to change is the ability to apply 'constructive' animation within the applicatoin. 2D animations and 3D animations. My imagination is running wild, I can only imagine the possibilities.

Theres countless other benefits from a designer and designer/programmer stand point.