Don Box: XAML is just an XML-based way to wire up CLR types
no more no less... XAML is domain-neutral, so while it may be
used to create desktop apps, web pages, and printable documents, it
could also be used to create CRM apps, blogging backends, or highly
concurrent web services provided you had a supporting CLR-based
library to do the heavy lifting.
I guess that clears that up.
Ah, Microsoft yet again tries to pass off something as their revolutionary idea ! :-)
XAML is basically ASP.NET for the desktop. Somehow everyone and their mom sees this as competing with their favorite pet technology be it HTML, Javascript or CSS.
Someone needs to smell coffee. It's either the persons that think Windows is the only desktops out there or the persons that thinks there is a better desktop than windows. In my eyes both are wrong :-)
You will see stronger competition on the desktop market in the future (OSX, Linux, mobile, tv and other embedded devices. Users should become more free to choose what applications they should run independendt of the development plattform.
Microsoft is a good company with smart people. They shouldn't be afraid of competition on the desktop and in the future I hope they will support other desktops as well.
"XAML is basically ASP.NET for the desktop. Somehow everyone and their mom sees this as competing with their favorite pet technology be it HTML, Javascript or CSS." you said
So you mean XAML is the thing that will replace my WYSIWYG control designer? I'm to tired of moving controls some pixels in a markup language. I hope that XAML can be used for something more exiting.
Dare, when I read Chris Anderson's History of XAML, I too was left with the strong impression that this was something akin to XUL.
FWIW, I closely followed but intentionally did not contribute to all of the pre-PDC hand wringing. My best guess at the moment is that while Chris's rendition is presumably historically accurate, Don's description seems more complete, and therefore more useful.
That being said, I can't reconcile Don's description with the statement XAML is basically ASP.NET for the desktop. Care to elaborate?
Sam,
I don't know enough about XAML to actual make any sort of definitive comments about it. If anything I withdraw my statements about it being "ASP.NET for the desktop" given that this is merely the impression I got from reading Chris's blog and some samples I have seen online.
Chris is an Avalon architect and Don's played with it a bit so their statements should be considered a lot more worthy of mention than mine. If anything, you're best off asking questions in Chris's blog since he seems to respond to those.
"XAML is just an XML-based way to wire up CLR types - no more no less. Given the appropriate namespace decls, the following is legal (albeit useless) XAML:
<Object def:Class="MyClass" />
which is equivalent to the following C# fragment:
public partial class MyClass : System.Object {} "
The question there is what exactly does Don mean by wire up?
His example suggests XAML can be used to actually declare a new type which is (IMO) very different to ASP.NET which maps purely to existing types (as does XUL).
The next step from what Don's suggesting involves having something to define class methods in XAML. That road seems to head in the same direction as XBL which is also well trodden Mozilla ground, for example.
I'd like to give Sun NeWS some credit here. This was the postscript based system where you could upload rendering code and event handling to the client system, and still have the core of the app running remotely. It lost out to X11, not just because X11 had momentum, but because it was hard to write good NeWS apps that distributed well. Furthermore, the LAN-scale of late eighties distributed apps meant a key NeWS advantage -better long haul responsiveness was moot.
Regardless of who can take credit for XAML, I can only view it as a good thing. So far the sole 'distributed app architecture' that has succeeded is the web browser front end, something server side responding to the requests. XAML does at least offer better UI options that classic web page designs, without forcing everyone to reroll their own custom widgets, a la DHTML or SVG. Too bad it isnt cross platform.
I am also going to observe that it is a shame that Sun havent got a good Java alternative. What if the JRE shipped with XUL support built in, eh? Or if there was an XML syntax to create SWT components. The whole Java UI design methodology harkens back to X toolkit coding, programatically creating widgets and layout controllers. The closest we have is Jelly.
In the case of XAML, "wire up" means one or more of the following:
1. Define a new CLR type.
2. Instantiate existing CLR types.
3. Set the values of properties.
4. Register event handlers.
In the case of #1, you're really defining PART OF a CLR type - the XAML compiler allows you to combine a VB or C# (or ...) source file using the partial class support in the new whidbey compilers.
What if the JRE shipped with XUL support built in, eh? Or if
there was an XML syntax to create SWT components. The whole
Java UI design methodology harkens back to X toolkit coding,
programatically creating widgets and layout controllers. The
closest we have is Jelly.
You might wonna check out the Luxor XUL Toolkit @ http://luxor-xul.sourceforge.net for creating Swing or SWT widgets using XML. For more alternative XUL motors/browsers/runtimes in Java check out the XUL Alliance @ http://xul.sourceforge.net
I am also going to observe that it is a shame that Sun
haven't got a good Java alternative.
Well, Sun hates XUL because evidently it competes head-on with the upcoming Java Server Follies (JSF) package. See the Viva site for more insight @ http://viva.sourceforge.net/action.html
Don, not only is that clear, it also explains the analogy to ASP.Net... the partial class support leads to a similar programming paradigm as one would use with ASP.Net's "code behind" pages.
I am a bit surprised that there is no ability to call methods. The stock VA demo from years ago allowed one to create a simple "todo list" program with NO code.
P.S. The overlap in our interests never ceased. :-)
I have proudly quoted myself three times since I heard about XAML a few weeks ago.
This is not the only piece about using an XML persistence format for Windows forms that you will find in the DOTNET mailing list. Many .NET newbies and experts came to the list with the idea (it is just that I cannot find others).
So if me (the epitome of a .NET wannabe) had then the hunch that something like XAML was the right way to build Windows applications (and the visual designers in Visual Studio), chances are that there was already a team at Microsoft already outlining Avalon by that time.
On the other hand, why use XUL if mapping .NET classes to XML elements is more powerful for this specific purpose? You can always write a XUL parser for .NET later if you need to.
This is not Microsoft claiming that they created the Internet. They are just doing at last what they had to leave undone in version 1.0 and 1.1 of the .NET framework.
Don Box: Today, the data needed to initialize an object graph is hidden behind imperative statements in your programming language of choice. That makes it difficult to tease out of the rest of your program without weird markers in the source code to ...
Few years ago while I was in college I attended a course of X11 GUI. Although it was a french spoken course the whole picture resembled as an impressive architecture.
There were a few points I noticed (though I do not have good experience) which stand out:
1. GUI engine independence of the platform. You could start a process on a server computer and all the user interface would be running on a total different computer. It was nice to run Netscape in a SUN server while displaying on a linux box. Quite an amaising technology
2. The user interface was described in text files (as resources) which could be changed without the need of recompiling the whole program.