Windows Now

October 2004 - Posts

• Attribute grammar for xaml attributes

  Posted by rrelyea to Rob Relyea on Oct 09 2004, 09:09 PM

  Filed under: WinFx, XAML, Avalon

  We have a bit of a mess in our processing for attributes.  First, a list of the mess, then a brief description of the fix we plan.

  Attribute values in xaml can map to:

  1) a Literal value
     <Balloon Color=”Red” />
  We use the type converter from the type of the Color property.
  I'm happy with this.

  2) Star syntax.
      “*null” - sets the property to equals null.
      “*ClassName.StaticMember” - sets the property to equal the static member
      “*ClassName(PropertyName1=PropertyValue1,PropertyName2=PropertyValue2,...)” - we call this compact syntax.  it is most used for databinding - *Bind(Path=LastName), but has a few downsides - a) allows any class to be set this way (on top of the already possible property tag syntax). b) syntax doesn't solve all nesting, escaping problems.
      “*typeof(ClassName)” - set the property to equal the Type ClassName.
      “{ResourceName}” - if being set on a FrameworkElement or FrameworkContentElement, calls .SetResourceReference(); 
      I don't like the fact that the xaml parser builds in knowledge of Resources, an Avalon framework feature.

  3) Event Handler Name
      <Button Click=”onclickhandler” />
  I'm happy with this.

  --------

  We plan on changing the star syntax to something called “Computed value”. (not thrilled with the name)
  We'll build one extension mechanism into the parser and allow different users of xaml to build their own extensions. 

  One thing this will allow is to remove the knowledge that the xaml parser has of the Avalon framework feature - Resources.

  The xaml parser lives in PresentationFramework.dll, but one of the key goals is to continue to untie it from the Avalon framework.  In version 1, we'll likely still ship it in PresentationFramework.dll, but conceptually we are designing it as if it was in WindowsBase.dll - it should define well factored extensions that are based on different CLR concepts - existing concepts when possible - new ones when necessary.  TypeConverters, IList, IDictionary, etc...

  As part of this change, the flexibility that people have with compact syntax will be reduced.  Today, they can use *Bind(), *Button(), *AnyClass() in any attribute.  We'd like to restict this to a small set of classes that are explicitly in need of being set in an attribute.

  I'm not going into great detail in the description of our fix because I'd prefer to be the first company to ship our design.  :-)

  So once we do this work, we'll have:

  1. LiteralValues - go through type converters.
  2. ComputedValues - go through 1 well defined extension mechanism to support scenarios that need to be handled in attributes that map to many different Types.  Bind and ResourceReference, for example, can be used to set Height, of type Length, or to set Background, of type Brush.  We don't want to change all type converters to know about Bind and ResourceReference.
  3. EventHandlers
  

  8,950 Views

• new Xaml terminology.

  Posted by rrelyea to Rob Relyea on Oct 05 2004, 03:01 PM

  Filed under: WinFx, XAML, Avalon

  Among other things, I (and my teammates) have spent much of the last year designing significant improvements to xaml2003 that you saw at the PDC in October 2003.  While we have spent a lot of time investing in design, we haven't implemented many of the changes yet.  As such, I hadn't wanted to do much posting yet.

  I got back from vacation last week and found out that we'll continue some implementation very soon.  I'm very excited!

   

  A few things to restart the flow of info about what we are doing...

   

  Processes that involve Xaml & Baml

  XamlLoading - process of loading xaml and creating objects.

  XamlSaving - process of saving an object and all related objects to xaml.

  XamlCompiling - process of creating code and a binary representation during compile time.

  BamlLoading - process of loading code/binary representation during run time.

   

  People used to throw around a bunch of terms for these things: Parsing, Serialization, etc…

  Right now, we think that list is clear and well defined.

   

  Syntax Terminology for setting properties via markup

  Attribute Syntax - Setting a property with an xml attribute

      <Balloon Brush="Green" />

   

  PropertyTag Syntax - Setting a property with a PropertyTag contained inside the ObjectTag (Balloon).  The PropertyTag denotes which property you are trying to set on the outermost ObjectTag.  The content inside the PropertyTag provides the value.

      <Balloon>

        <Balloon.Brush>

          <SolidColorBrush Color="Red" Opacity=".5" />

        </Balloon.Brush>

      </Balloon>

  (Previous names - Complex syntax.  Compound syntax.)

   

  Content Syntax - Many objects will have a property that is the ContentProperty.  For example:

      <Button>Hello</Button>

  will effectively create a Button and set Button.Content="Hello".

   

  For a long time, we've relied on IAddChild and let component authors decide what their ContentProperty was.  We're hoping to decorate types with that information and remove IAddChild from Avalon.

   

  ---

   

  Crazy busy for the next several weeks, but I'll try to keep some things coming...

   

  -Rob
  

  7,132 Views