Rob Relyea


November 2003 - Posts

  • HelloWorld.xaml (for Avalon, not Console)

    Filed under: , ,

    Don was showing how XAML was not just about building trees of Avalon Elements with his K&R flashback.  That's true: XAML can be used to build (a) element trees, (b) element trees with logic, or (c) class definition.


    I don't want people to become too focused on the programming model for building console applications.  That is not our focus!  Markup won't add much value there.  Don showed a good example of the flexibility for defining new classes with XAML, but that will much less common than the other uses of XAML.


    Given that, let's start with a simple Hello World and show where we'd like you to be able to take it.



        Hello World!


    What are the next few interesting things you are going to do with Hello World and how easy can we make that?


    FadeInWorld.xaml [1]



                Begin="0" Duration="3"

                Fill="Hold" />


        Hello World!


    You can animate most properties in Avalon.  Here we use a CompoundProperty tag - .  Inside we put a DoubleAnimation.  Opacity is of type Double.  Most properties in Avalon aren't strings, but instead real types like Double, enums, Uri, etc...

    This animation will change the Opacity from 0 (hidden) to 1 (fully visible) in 3 seconds.  At the end, it will hold the final value.


    CircleWorld.xaml [2]


        Hello World


    Avalon allows you to mix UI, Documents & Media.  Here we are mixing in Vector graphics (Ellipse).




        Hello World!


    Avalon allows you to have rich text.


    InteractiveWorld.xaml [3]





            void SayIt(Object sender, ClickEventArgs e)


                b1.Content = "Hello World!";





    Avalon allows you to put interaction logic in the .xaml file or in a code behind file (.xaml.cs if you choose to use C#).  Because XAML is well-formed XML, you will sometimes need a CDATA section to make sure that characters in the code won't inadvertantly be treated like a close tag.


    There are other concepts to show in XAML, but I’ll leave it at that for now…




    [1] I've simplified our current animation syntax for this sample.  PDC bits require a DoubleAnimationCollection tag that contains the DoubleAnimation.

    [2] I didn’t run this sample, as I don’t have a Longhorn machine at home.  I’ll update this sample if it doesn’t work…

    [3] PDC bits require this to be compiled as part of an application/document.

  • Why is XAML well-formed XML?

    Filed under: ,
    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 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.

    I’ll respond:

    XAML is XML because

    We believe that making XAML be XML is the right thing to do because:

    1.      Without extra work from the vendors involved, we’d like all XML editors be able to work with XAML.

    2.      We’d like transformations (XSLT, other) be able to move content to/from XAML.

    3.      We didn’t want to write our own file parsing code, the parser code we do have is built on top of System.XML.XmlTextReader.  We are able to focus on our value add.

    4.      I’m sure that there are several more reasons…

    But XML isn’t Perfect

    That all said, there are a number of things that we’d like to do in XAML, but XML isn’t a perfect fit.

    1.      We want to enable setting the Background property on a Button (for example) in one of two ways:

    a.       Using a normal attribute -<BUTTON Background="”Red”">Click Here</BUTTON>

    b.      Using our compound property syntax –

                <GRADIENTSTOP Color="”White”" Offset="”0”" />
                <GRADIENTSTOP Color="”LightBlue”" Offset="”1”" />
        Click Here

    c.       Ideally if somebody tried to use both syntaxes at the same time, we could error.  XML Schema – as far as I am aware – isn’t well equipped to describe that behavior.

    2.      It is a bit strange, for designers or developers moving from HTML to XML.  HTML is forgiving.  XML isn’t.  Should we shy away from XML so that people don't have to quotes around things?  I think not.

    3.      It is difficult to keep XAML as a human readable/writable markup, as that isn’t one of XML’s goals.  I think it needs to be one of XAML’s goals.  It is a continual balancing act.

    Dare says I'm wrong on this last point.  XML's goals do say that:
    6. XML documents should be human-legible and reasonably clear.
    So, yes, they are meant to be readable.

    The issue I wrestle with is:
    10. Terseness in XML markup is of minimal importance.
    That impacts the writability. One example is our compact syntax versus compoundproperty syntax. I'll do a post on that question at some point.

    What do you think?

    I’m interested in more detailed feedback about why XML isn’t an appropriate direction for us.  My brief look at XQuery after searching in the IE address bar for “XQuery Primer” brought me to this “What is XQuery?” page – it compared XQuery to ASP syntax – sounds like you are perhaps interested in mixing directives in the middle of the markup to generate content as appropriate.

    We have purposely chosen not to support this concept (Response.Write in ASP, Document.Write in DHTML, etc…).  We do provide a number of ways to make the content of a element tree dynamic – the primary method being DataBinding.

    Everyone – let us know the scenarios that being XML enables or prevents.  We’d love to hear your opinion here.


  • Slides and Demo code from Cli300

    Filed under: , ,

    My demos have been posted for a while.  My slides must have gotten lost in the mail...

    Now it all seems to be posted:

    My session was CLI300.  Let me know if you have any questions/comments.  I'll post a screenshot of my demo at some point, for those of you without Longhorn.

    In the demo, the most interesing xaml files to take a look at:

    Pane1.xaml - main page of the demo (see how to style RadioButtons radically, how to get started with DataBinding a listbox, see the basics of styles, etc...)

    The following are in the Sessions subdirectory:

    Cli300Description.xaml - see a flow document

    Cli300Slides.xaml - see a fixed format document - i created this by printing my slide deck in powerpoint to the windows client print driver (i did have to trim the document down to just a few slides so my demo didn't go badly :-)  -- that'll get better.

    CLI300DemoCanvas.xaml - a small sample of xaml using the Shapes

    CLI300DemoDockPanel.xaml - a demo of the DockPanel in action

    CLI300DemoFlowPanel.xaml - a demo of the FlowPanel in action

    CLI300DemoGridPanel.xaml - a demo of the GridPanel in action

    Sessions.xml - the xml file that Pane1.xaml databound to.

    I'll (or others) will eventually post more about all this stuff...

  • Tools in PDC Bits for Building Longhorn Apps - XAML, etc...

    Filed under: , ,

    I'm going to try to start posting my comments answers that others may find good info in on my blog, not just as comments on people's site.

    Sam Gentile posted:

    I just realized that the Longhorn SDK adds templates to VS.NET Whidbey so you can use it to create Longhorn applications. Using the C# Longhorn Application template/wizard generates a solution with the XAML file specifying a C# code-behind class (implemented as a partial class). I'm going to have to play with this some more although I don't prefer this route. Like 3 years ago with .NET, I believe the SDK, an editor and the command line are by far the best way to learn the technology.

    I commented:

    The current VS.Net Whidbey solution to build Longhorn Apps won't be hiding much from you. (PDC attendees received this...MSDN subscribers go here )

    It will:
    1) give you an easier start, as it will create several files for you, which you can them modify.
    2) give you xml intellisense in your xaml.
    3) give you c#, vb, or c++ intellisense in your code behind.
    4) maintain the .csproj file for you -- although you can modify by hand as well.

    If you plan on only using notepad and msbuild, that is workable, but tougher.
    If you do, check out xamlc.exe - give a xaml page, it will hide the msbuild process (won't require a .proj file or MyApp.xaml).

    That all being said, I'm excited that this is public now. We are looking forward to working with the community to make sure that WinFx, the new Windows API, and XAML, our Xml markup language, provide what developers need.

  • XAML Tour

    Filed under: , ,

    So I've described the 5 families of Avalon Elements: Panels, Controls, Shapes, Decorators, & ContentElements.

    In order to describe how XAML is used to build Element Trees (see XAML: Element Trees, Element Trees + Logic, or Class Defintion), here is the list of the next posts I plan.  I'll update this list as my plans change and add links as I write the posts.

    • Using Controls
    • Using Panels
    • Building Flow Documents Using ContentElements
    • Using Shapes
    • Building Fixed Documents
    • Using Decorators
    • Setting Properties via Compound/Compact Syntax
    • Resources/Styling
    • Animation
    • Databinding


    Please give me feedback along the way if there are other topics you have interest in.

  • XAML: Element Trees, Element Trees + Logic, or Class Definition

    Filed under:

    There are 3 main ways to use XAML.
    1) to define a tree of elements with animations, databinding, etc...
    2) to define a tree of elements (as in #1) with programming logic behind it
    3) to define a new class

    #1 doesn't require compilation of the xaml.  I'll be posting some details on #1 in the next several days.
    Today #2 & #3 do require compilation of the markup.

    Details behind Trees of Elements with Logic (#2)
    The way we accomplish #2 is to build a new class.
    <DockPanel> ... </DockPanel>
    with no def:Class attribute will build what we refer to as an anonymous class.

    <DockPanel def:Class=“MyNS.MyPage“> ... </DockPanel>

    will build the MyPage class in the MyNS namespace.

    I can show this page in an Avalon application, by

    a) navigating to SomePage.xaml (we'll know to go run the appropriate code and load the appropriate binary representation of the tree from a .baml file)

    b) writing code (similar to this):
    MyNS.MyPage page = new MyNS.MyPage();
    someNavigationContext.Navigate(page);  //navigationContext could be a navigationwindow or a

    To go explore the details here, go look in obj\debug or obj\release for some *.g.cs files -- these are the output of our markup compilation.  (As always, if you are using vb, you can look for the same thing with a different extension *.g.vb)

    Example of building a class in XAML (#3)
    Don shows a great example of building a HelloWorld console app with XAML.

  • Avalon's 5 Element Families

    Filed under:

    XAML has been discussed a bunch lately.  It is easiest to show people what it is in person, but since that won't scale, I'll try to convey the same points by posting markup samples, descriptions and screenshots.


    Avalon, Longhorn & XAML

    Avalon is a presentation platform for the next generation of Windows (“Longhorn“).  XAML is a markup language that can be used on Longhorn for many things including creating desktop apps, web pages, and printable documents.  The system is very extensible.  If you want to build your own set of elements, you have the power to do that.  If you want to mix those elements with ours, you can.  If you want to just use yours, you can.  If you don't like angle brackets and would like to use only code, you can do that as well.


    That being said, let's talk about the 5 element families that Avalon has in the build we just released at the PDC: Panels, Controls, Shapes, Decorators and ContentElements.



    Elements which Measure, Arrange and Render their children in the element tree (DockPanel, FlowPanel, TextPanel, etc…)



    Elements which provide keyboard and mouse interaction models for the user (Button, TextBox, etc…)



    Elements which will render vector shapes (Ellipse, Rectangle, Path, etc…)



    Elements that can contain 1 child, and will adorn or affect the rendering of that child. (Border, TransformDecorator)


    ContentElements*  (needs renaming)

    Elements which provide semantic meaning for a documents structure (Paragraph, Section, Heading, etc…) and a few formatting tags (Bold, etc…)


    Using elements from those 5 families, we are trying to enable developers & designers the power to build great user experiences for Windows “Longhorn“.  We also want to provide a consistent markup and programming model experience in all of these element families.


    In future posts, I'll drill down in each of these families, showing some markup and code examples and pointing you towards more information from our SDK and blogs.

  • Finally something to blog about...

    What led to this blog
    The PDC was a great experience for me.  I gave a talk about the basics of Avalon's Markup & Programming model.  I spent a ton of time reading blogs and newsgroups and trying to help clarify things when I could.  I loved talking to people about Avalon.

    Now I'm finding myself leaving longer and longer comments on peoples blogs.  That is probably bad form. (?)

    Anyway, I'm going to begin posting to this, my first blog.  I've been reading Dave for years.  I'm just starting to use an aggregator to more easily read other's blogs.  I imagine that blogging will be fun.

    A little about me
    I'm a Program Manager on the Avalon Team.  Program Managers write specs, help design features, triage bugs, and whatever else is necessary to “ship the right product at the right time.”  Being part of the software creation process is a joy.  I've been on the Avalon Team since its start.  Before that I focused on IE's programmability (primarily DHTML).

    Things I focus on at work:  XAML, developer experience for Windows users, Avalon Programming Model, making sure that different languages and tools can target Avalon, MsBuild integration, ...

    What I plan to post
    I plan on posting primarily on Avalon and XAML topics with this blog, but we'll see what happens.

    My first set of posts will be a walkthrough of the talk I gave at the PDC (cli300).  In that talk, I showed a couple slides, but spent most of my time writing XAML and C#.  I haven't written the posts yet, but I hope to be able to convey all the information I got across in the talk, which was well received.

    Thanks to LonghornBlogs for hosting my blog.