It’s just data

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 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?

What about Dynamic HTML?  Namely the ability to modify the rendering and content of the document on the fly?  Isn't that lost by a compile to bytecode approach?


RE: No dynamic XAML?

sigh

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.

Message from Dare Obasanjo at


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.

Posted by Gary Burd at

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.

Posted by Dare Obasanjo at

"Apparently, one can embed small amounts of code in the markup ... This corresponds roughly to the role that JavaScript plays in HTML... or does it?"

XAML with code must be compiled, whereas JavaScript is interpreted; so the two are not analogous.

Posted by Filipe Fortes at

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.

Posted by Don Box at

Dare,

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.

Posted by Gary Burd at

Again, this really has little to do with XAML - it's an Avalon thing.

Bear with me, Don, I'm trying to map ontologies here.  ;-)

Posted by Sam Ruby at

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.

  More info @ [link]

Posted by Gerald Bauer at

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.)

I imagine XAML works similarly.

Posted by Oliver Steele at

Gerald,

Don't confuse XAML with Avalon.

Avalon is the managed CLR-based framework we use for letting humans interact with their computers (including output devices like printers).

XAML is but one way to stitch together CLR-based classes, some of which may be from Avalon.

DB

Posted by Don Box at

XAML is but one way to stitch together CLR-based classes,
some of which may be from Avalon.

  Don, why not tell it like it is. Microsoft replaces all open formats such as HTML, XUL, SVG, CSS, PDF and many more with inbreed Windows-only APIs (aka Avalon CLR classes).

  The XAML format, of course, is just one option to lock you into the upcoming Longhorn Windows money machine.

  - Gerald

Posted by Gerald Bauer at

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

Posted by Rob Relyea at

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.

  -- Chris Anderson (Avalon Core Developer)

Posted by Gerald Bauer at

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.

I guess that clears it up, doesn't it?

Posted by Gerald Bauer at

Sam Ruby asks "no dynamic XAML?"...

Excerpt from The Scobleizer Weblog at

One specific technical question to Don, related to parsing XAML vs. parsing ASP.NET;

In you hello world example, let's say I add some HTML to output e.g.

  <def:Code><![CDATA[
  Shared Sub Main()
  {
  System.Console.WriteLine("Hello, world");
  }
  End Sub
  ]]>
  </def:Code>

No problem in this case but with ASP.NET page you might have;

<script runat="server" language="C#">
void Page_Load ( Object Src, EventArgs E ) {
  System.Console.WriteLine("Hello, world");
}
</script>

A strict XML parser is going to have some issues with that.

Will there be some mechanism to convert ASP.NET to well formed XML?

Otherwise, on a more general level, reading things like "like SVG" or "similar to CSS". How about "supports SVG" and "uses CSS"?

Posted by Harry Fuecks at

Aaargoops...

Please read < b >world</b > where you see world in above examples

Posted by Harry Fuecks at

What is XAML?

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.

X# anyone?

Posted by Invalid Assertion at

Harry,

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 &lt;[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.

Posted by Don Box at

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...

Excerpt from DonXML Demsak's at

I call them Avalon Elements.  We have 5 families of elements - see [link]

Posted by Rob Relyea at

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?

Posted by Gerald Bauer at

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.

Posted by DonXML Demsak at

SVG (and the XML browser vision) has really gone nowhere in 3 years.

Well, isn't it because Microsoft has frozen Internet Explorer for years? Evidently, Microsoft has no interest in working together with others to build a rich internet for everyone instead Microsoft wants it all for themselves.

Posted by Gerald Bauer at

Yes Sam, it is dynamic...

Avalon is very very dynamic......

Excerpt from simplegeek at

NO SAM, IT IS NOT DYNAMIC AT ALL...

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.

Posted by George Mladenov at

George, it looks like you missed ChrisAn's post on Parser.LoadXML, which supports on-the-fly creation of object graphs from XAML.

See [link]

DB

Posted by Don Box at

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.

Posted by George Mladenov at

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'.

Posted by George Mladenov at

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...

Excerpt from DonXML Demsak's at

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.

Posted by Invalid Assertion at

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]

Posted by Gerald Bauer at

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.

- Gerald

Posted by Gerald Bauer at

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.

Posted by Mark at

XUL is just some interface language some guys made up and
only Mozilla implements.

  Well, XUL has outgrown Mozilla long ago. For a start, check out the Luxor XUL toolkit online @ [link] or the XUL Alliance site online @ [link]

Posted by Gerald Bauer at

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.

Posted by George Mladenov at

XAML (unlike ASP.NET) is well-formed XML, so you'll note that &lt;[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.

Posted by George Mladenov at

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.

Posted by Invalid Assertion at

See my response to the Why is XAML well formed-XML at [link]

Posted by Rob Relyea at

XAML Passes the XML Litmus Test

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...

Excerpt from Dare Obasanjo aka Carnage4Life at

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...

Excerpt from bLOGical at

Dynamic XAML is here, check out Xamlon at www.xamlon.com. XAML for Windows.Forms on .NET 1.1.

Posted by Paul Colton at

Why is XAML well-formed XML?

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...

Excerpt from Rob Relyea at

MyXaml is the real XAML for Windows Forms -- kicks Xamlon butt, in terms of features:
www.myxaml.com

Posted by Frank Hileman at

If you want an unbiased view of all XAML technologies, look at www.Xaml.Net

Posted by Ric Johnson at

I'll just casually note that the registration for xaml.net is set to expire before XAML is even released.

Posted by Mark at

Add your comment