Let's assume for a moment, that XAML is HTML "done right" for
rich clients (suspend disbelief if you have to). It
apparently has
SVG like elements, if nothing else. It doesn't have CSS,
but apparently there are
other ways of solving similar problems being proposed.
Apparently, one can
embed small amounts of code in the markup. Unquestionably
controversial, but often handy. This corresponds roughly to
the role that JavaScript plays in HTML... or does it?
I'm very curious as to where this XAML is intended to replace HTML meme started. All I've ever heard about XAML is that it is the new way to write Windows client apps. Your question is like asking where is the equivalent of doing "Dynamic HTML" in a Windows Forms application like RSS Bandit, the answer to that questions is "Why would I have to do that?"
DHTML arose because HTML was about static content. GUI widgets for the typical operating system are by definition not static.
I'll keep saying, the biggest mistake the XAML folks made was basing it on markup (XML specifically). Now everyone expects it to act like their favorite markup language. Funny enough, if I ever have to edit XAML by hand I'll consider it a failing of the next (next) version of Visual Studio.
The dynamic part of DHTML is the ability to make runtime modifications to the objects created from the static HTML description. The HTML description is not modified.
Although I don't have any direct knowledge of what's going on with XAML and Avalon, I expect that the objects created from XAML or a byte code compiled form of XAML can be modified at runtime. In this sense, XAML is dynamic.
DHTML has the ability to create and HTML description of the the runtime state and the ability to create new objects by injecting HTML at runtime. I don't know if there will be similar capabilities with XAML.
Gary,
What do you mean by runtime modifications? Setting properties and hooking up events? This is already the case with WinForms and I sincerely doubt that XAML/Avalon would take a such a ridiculous step back. If you mean adding properties to the class at runtime, this seems a lot harder and I suspect there are CLR limitations that would make this very difficult.
Filipe or ChrisAn can correct me, but the Avalon object model has read/write properties (some of which are collections), so I would be surprised if you couldn't modify things on the fly. I also believe there's a way to shove XAML into an Avalon control graph on the fly.
Again, this really has little to do with XAML - it's an Avalon thing.
One could conceivably use XAML to wire up a graph that froze once it was activated.
By runtime modifications, I am referring to the ability to set properties, hook up event handlers, call methods, create new objects and remove objects. As I said in my comment, I expect that XAML/Avalon can do these things and is therefore "dynamic."
You do bring up a point which I had not thought about. DHTML objects support the Javascript-style addition of properties at runtime. This was not pleasant to implement with plain old C code. There are probably similar issues with the CLR.
I'm very curious as to where this XAML is intended to replace
HTML meme started. All I've ever heard about XAML is that it
is the new way to write Windows client apps.
Dare, why not start with checking out the Microsoft Longhorn Dev Pow Wow (PDC) slide deck titled "'Avalon': Using the Document Platform Features" for some insight.
If I may quote the summary:
Integrated document services are a key component of "Longhorn". This session covers the end-to-end view of Windows "Longhorn" documents ranging from creation, to management, to consumption. Document scenarios include content-centric applications, stand-alone documents, and printing. Document-centric APIs and format are discussed in detail. Demos include document-centric application, adaptive flow and fixed documents, authoring via print driver, and more.
There's nothing inherent in the compile-to-bytecode approach that precludes modifying the document model at runtime. The current implementation of LZX (the Laszlo presentation markup language) compiles to Flash bytecodes that create an object hierarchy when the application is loaded. <script>, <method>, and event attributes within the XML contain JavaScript that can manipulate objects within this hierarchy, so you can do this:
<button onclick="new LzText(canvas, {text: 'my text', x: 100})">Click</button>
to create an object at runtime, or you can declare the object in XML for the same effect:
<button onclick="mytext.setAttribute('visible', true)">Click</button>
<text name="mytext" visible="false" x="100">my text</text>
(You can paste this into the Hello World example at [link] to try it out.)
JScript.Net is one of the languages that you will be able to use with XAML. Currently, it, like other languages, will need to go through a compile step.
Avalon is fully dynamic. When you use XAML to build an Element tree declaratively, you can get/set properties, call methods, wire up events, create more elements, etc...
Everything you would expect to be able to do.
-Rob
Program Manager, Avalon Team
I'm very curious as to where this XAML is intended to replace
HTML meme started. All I've ever heard about XAML is that it
is the new way to write Windows client apps.
Dare, for some fresh insight allow me to highlight some quotes from Microsoft Avalon bloggers collected for the XUL News Wire story titled "Inside Redhell: Microsoft XAML Blogger Round-Up" online @ [link]
XAML is a markup language that can be used on Longhorn for many things including creating desktop apps, web pages, and printable documents.
-- Rob Relyea (Avalon Program Manager, XAML "Spec Owner")
Our rendering model is very much like that of SVG.
Our markup isn't the same mostly because XAML is a direct reflection of the programming model.
Our object model (OM) doesn't match the SVG DOM because we choose to go with an object model that more closely matches what we think our users expect.
XHTML and SVG both have image elements. We avoid this duplicity. Text is another area where we avoid a large amount of duplication.
-- Joe Beda (Avalon Core Graphics Developer)
We are past the world of generating static snapshots of display and blasting them down to a client.
My not-to-hidden agenda here is simple - dynamic applications should be dynamic on the client. The server should send data - either through web services, database access, or any other wire protocol - and the client should consume that data and generate UI. The model of a server trying to generate the correct display for a client is just broken.
I'm very curious as to where this XAML is intended to replace
HTML meme started. All I've ever heard about XAML is that it
is the new way to write Windows client apps.
Allow me to quote a last pricless gem from the Longhorn SDK docu page titled "Introduction to Adaptive-flow Format Documents" online @ [link]
Why the need for Adaptive-flow Format?
The advent of the World Wide Web posed several challenges for designers. Print media never required the adapting of layout to different media shapes. However, when pages were viewed using the World Wide Web, it was impossible to predict the size of the window in which the document would be viewed or the personal preferences that would be selected by the viewer. As a consequence, a document that looked great in one format might display poorly on another. While HTML and Cascading Style Sheets (CSS) made strides toward remedying this situation, the results were often less than ideal because the specifications were applied without regard to the readability of the page.
XAML is nothing more than an XML-based file format for storing information about a set of interrelated CLR classes and partial classes. The XAML file could be created directly by the programmer, through automation or through an interactive graphical designer. The XAML file itself can then later be compiled, possibly with related partial classes and other components, into a CLR application.
In the case of GUI designers, XAML (with help from partial classes) improves on the WinForms model by avoiding situations where the design tool deletes code written by the developer. It also opens up the opportunity for both manual editing and the creation of third party design tools. Using an XML-based format allows the designers and compliers to use standard XML parsing libraries.
How is XAML different from, say, XUL or SVG? I suppose the most obvious is that XAML uses a different set of foundation objects. But this is really quite an unimportant point. The most interesting thing about XAML is that is is not just a format for specifying GUIs; it is a format for specifing the code relationships for ANY related set of CLR objects.
What does this mean? It means that you could use XAML as the backing format for an interactive design tool that lets you design programming logic graphically. Or maybe it lets you design complex business orchestration scenarios. Or whatever. The designs could then be serialized to XAML and then compiled into CLR assemblies.
If field experience with ASP.NET is any indication, the recommended practice is that new members (methods, fields, properties, events) will happen in the .cs or .vb (or .ml) file, which reduces the problem.
Both ASP.NET and XAML allow members to be defined "inline" in the markup.
ASP.NET uses <script runat="server"/>.
XAML uses <def:Code/>.
XAML (unlike ASP.NET) is well-formed XML, so you'll note that <[CDATA[ gets used a lot. In fact, the PDC build of the XAML preprocessor requires it (this requirement should be relaxed before release).
Unless I'm rusty on my XML 1.0 productions, this means you get free reign unless the three character sequence "]]>" appears in your code. The techniques for dealing with this are well known if not pretty.
Thankfully the next version of VS (Whidbey) has a very solid XML editor that should smooth things over a lot.
And of course (sigh), visual designers inside of IDEs that mask the XML are likely to be the mass-market way developers interact with XAML.
Confusion Over the Name of the XAML Graphic User Interface Elements Subset
In reading various posts (including a small rant by Don Box in Sam Ruby’s Ruby’s No Dynamic XAML post) there seems to be major confusion over what to call the subset of XAML used in creating graphics and UI elements. Since XAML is much more than...
How is XAML different from, say, XUL or SVG? I suppose the
most obvious is that XAML uses a different set of foundation
objects. But this is really quite an unimportant point.
Have you realized that the web is build on standards? Only by working together can we build a rich internet for everyone. Is that so hard to understand?
I've been a big supporter of the W3C and SVG for 3 years now, and I must say that I'm very disappointed in the way that the W3C has handled SVG. There is a bunch of people from the svg-developers Yahoo Group that truly understood the potential power of SVG, and we have work very hard on trying to get the W3C to move on the vision of a true XML base browser that allows for rendering of multiple (and custom) namespaces. But thanks to the typical committee syndrome of discussion things to death and comprising until the final spec is a total mess, SVG (and the XML browser vision) has really gone nowhere in 3 years. The W3C has been building all these specs, with a total disregard to a common framework, which is a must for rendering of multi-namespaced documents. If you get a chance check out the work the XSmiles folks had to do to get a browser that could (partially) handle XHTML, SVG and SMIL, and you will see what I mean. Now, finally, Microsoft has stepped up to the plate, and they have come up with a way to render multiple XML namespaces in a browser agent, and people are complaining that Microsoft has a total disregard for standards. Hopefully, the W3C answers this wakeup call. There’s nothing like a little competition to motivate people to create some wonderful innovations. And in the end, as someone who tries to promote technologies, not the religious fervor behind some technologies, all I really care about is implementing the vision. I don’t care if Microsoft, the W3C, or some other party get it done, because once more than 50% of the desktops are using it, it becomes the standard.
At least not in the DHTML sense of this word. You will not be able to do something like this with XAML:
tableElem.Write("<Button Click="OnClick">OK</Button>");
That's because XAML does not exist at runtime. XAML is a declarative syntax for writing your program. It is better than writing code but at the end of the day it's still the same, since it does get compiled to code. You can still modify the Element tree at runtime but you will have to do it programmatically.
The MS guys are in denial when it comes to dynamic XAML. Whenever somebody asks this question, the answer is always that yes, of curse XAML is dynamic. The truth is, if you want to insert a new button in your form, you have to write code for that - it is not possible to just modify the markup and have your button inserted. I was also hoping that XAML would be HTML "done right". The good news is, we now at least have VB done right. Hopefully in Longhorn 2.0 they will fix HTML too.
JScript.Net is one of the languages that you will be able to use with XAML. Currently, it, like other languages, will need to go through a compile step.
Rob, I understand why XAML needs to be compiled. For a lot of applications it does make sense to be compiled. However, why not also have the ability to render XAML at runtime and bind to event handlers in already compiled assemblies? This is different than parsing JScript at runtime and also different than compiling XAML at runtime. I am asking about parsing and rendering XAML at runtime and binding to already compiled code.
Don,
I did not miss ChrisAn's post. He exmplicitely mentions that the 'XAML can't contain any def:Code fragments, because at this time we don't do dynamic compilation on the client during parsing'. The way I intrepret it is that 'yes, actually you can load dynamic XAML if you compile it before that'.
Confusion Over the Name of the XAML Graphic User Interface Elements Subset
In reading various posts (including a small rant by Don Box in Sam Ruby’s Ruby’s No Dynamic XAML post) there seems to be major confusion over what to call the subset of XAML used in creating graphics and UI elements. Since XAML is much more than...
Have you realized that the web is build on standards?
XUL is based on a set of Mozilla specific foundation objects.
Java applets are based on a set of Java specific foundation objects.
Flash programs are based on a set of Flash specific foundation objects.
SVG programs are based on a set of SVG specific foundation objects.
I just don't see how XAML threatens the "standards" of the web just because it is based on its own specific set of foundation objects.
Why not also have the ability to render XAML at runtime and
bind to event handlers in already compiled assemblies? This
is different than parsing JScript at runtime and also
different than compiling XAML at runtime. I am asking about
parsing and rendering XAML at runtime and binding to already
compiled code.
George, compilation or interpretation. Nowadays it's all the same. Check out the new Groovy language for some insight online @ [link]
I just don't see how XAML threatens the "standards" of the
web just because it is based on its own specific set of
foundation objects.
I guess you can't connect the dots. Microsoft has frozen Internet Explorer for years and refuses to support SVG, XUL, XForms and other next-gen markup languages for a rich internet for everyone. Instead Microsoft now unveiled its very own all-in-one Windows-only markup language that competes head on with HTML, SVG, XUL, CSS, PDF, and many more open formats.
OK, I'm no Microsoft fanboy, but Gerald is just being ridiculous now. XForms hit W3C Recommendation status on October 14, 2003 -- literally less than a month ago. PDF is publicly documented and royalty-free, but it's still 100% controlled by Adobe. XUL is just some interface language some guys made up and only Mozilla implements. Next-gen markup languages? You mean XHTML 2? It's still in Working Draft status. They're still renaming basic elements. What exactly did you expect Microsoft to do with it?
There's a case to be made here, but you're not making it.
George, compilation or interpretation. Nowadays it's all the same.
Yes, you can always ship your application/framework with a runtime compiler instead of a runtime interpreter and make it all the same. The question is does it make sense to do it. Downloading JScript as a source file and then interpreting it in the browser at runtime is a monstrosity. On the other hand, compiling markup that does nothing else than specify the layout and the appearance of your UI is a monstrosity too. You should use the right tool for the job. Procedural code should always be statically compiled, and it should be possible to interpret declarative markup at runtime.
It’s a good thing that XAML cannot be loaded in the browser if it contains def:Code fragments. It should be possible to load it, however, if it contains references to already compiled code. The way it is right now is quite useless.
Also, it should be possible to do DHTML style editing of the Element tree, e.g. elem.Write(“<xaml/>”). I did not get myself very familiar with the new XPathDocument class, but I think this class will allow writing XML directly into a document instead of using the DOM methods. It should be the same with XAML.
Also, it should be possible to navigate the Element tree using XPath. For example:
Button b = dockPanel.Item(“xpath_expression”)
This, together with the DHTML style editing, would be the killer features of XAML.
XAML (unlike ASP.NET) is well-formed XML, so you'll note that <[CDATA[ gets used a lot. In fact, the PDC build of the XAML preprocessor requires it (this requirement should be relaxed before release).
Why does XAML need to be (well-formed) XML in the first place? XQuery is not XML and yet it’s way better than XSLT, since its syntax is more expressive, readable, and intuitive. XAML does need to be interoperable and interchangeable between platform-independent web services. It will most probably be consumed only on Windows and (most probably) MS will come up with a XAML parser. Why does XAML need to be XML then. Why not have an expressive, readable, and intuitive syntax for doing the things that XAML was designed to do – seamlessly mixing markup with code.
Microsoft has frozen Internet Explorer for years and refuses to support SVG, XUL, XForms and other next-gen markup languages for a rich internet for everyone.
Using the same logic: Microsoft's refusal to release a new version of Windows for at least 2 years indicates their abandonment of the desktop platform. Lets face it, Microsoft isn't known for its timely releases.
Note that PDF and Flash have both achieved ubiquity on the web with no significant help from Microsoft. Java has succeeded in spite of legal fights and direct competition from Microsoft.
Note that there are third party controls for SVG (Adobe) and XForms (IBM I think). Its just that there is little in the way of actual content on the web for these standards.
By the way, as I understand it, XAML support in IE is implemented using controls just like Adobe's PDF and SVG control.
Instead Microsoft now unveiled its very own all-in-one Windows-only markup language that competes head on with HTML, SVG, XUL, CSS, PDF, and many more open formats.
Not that I'm quite as optimistic about XAML as you but you'd think that if someone unified half a dozen or more standards we'd all be celebrating. If this had happened in the field of physics there'd be a Nobel prize involved.
George Mladenov asked Why does XAML need to be (well-formed) XML in the first place? To which Rob Relyea responds with the following reasons 1. Without extra work from the vendors involved, we’d like all XML editors be...
No dynamic XAML?. Let's assume for a moment, that XAML is HTML "done right" for rich clients (suspend disbelief if you have to). It apparently has SVG like elements, if nothing else. It doesn't have CSS, but apparently there are other ways of...
In a comment, George Mladenov asked: Why does XAML need to be (well-formed) XML in the first place? XQuery is not XML and yet it’s way better than XSLT, since its syntax is more expressive, readable, and intuitive. XAML does need to be...