Ability to set nested properties without full verbose syntax <RichTextBox SpellCheck.IsEnabled="True" />

[petar-k-marchev]

While most of the components that are usually built in the framework (Button, TextBlock, etc.) do not require such a nested property syntax, third party controls are often more complex, composite, and would benefit greatly from such support. Please see the example below where now a gauge control requires 5 lines of XAML in order to set a single a property, but with nested syntax, lines count drop to 1:

Verbose syntax:

<telerik:RadRadialGauge>
 <telerik:RadRadialGauge.Axis>
  <telerik:GaugeLinearAxis Maximum="200" />
 </telerik:RadRadialGauge.Axis>
</telerik:RadRadialGauge>

Nested property syntax:

<telerik:RadRadialGauge Axis.Maximum="200" />

[petar-k-marchev]

For some mysterious reason the Verbose syntax XAML is not shown correctly as it is missing the "less than" and "greater than" signs in the first two rows.

[MovGP0]

@petar-k-marchev you forgot to escape your code with three backticks: \ ```XAML code ```

[skendrot]

Verbose is needed because you are setting an object. The Axis property of the RadRadialGauge is an object and could easily be null

[birbilis]

Could instantiate the parent object automatically if it has a default constructor

[GeraudFabien]

You also can use style (Setter) to write it once and keep the agility. I don't know how you can implement what you. For your exemple Telerik could have make somethinks easyer but with this particular syntax they let you built your own "GaugeLinearAxis" class or maybe they have many implementation themself (I don't know how telerik work.). What you said is like saying (tell me if i'm wrong) <UserControl <!-- Some Namespace here --> Content.TextBlock.Text="HelloWord"/> I add "TextBlock" for understanding. With your proposal you dont specify it. You don't even know what type you must create.

[petar-k-marchev]

Thanks guys. Verbose syntax is indeed needed when you have to set an object (the Axis in my example). But when the property is already set (it might have a default value or it may be readonly) then the nested syntax is going to be very helpful. Also, note that I did not suggest that an Axis element should be created. It shouldn't. And that is part of what I am suggesting - minimize creation of objects. What I am suggesting is to purely have the ability to set a nested property, because it is very convenient at times.

[birbilis]

wouldn't mind a null check (instead of throwing an error) and instantiation of the parent object if missing (isn't there type information available?)

[mossyblog]

Isn't this the purpose of a DataType in ResourceDictionary? .. that is you use the ResourceDictionary route to define a Data Template first.. ie the structure of the said layout so its reusable. Then seperate to this you define a Style Template which then arranges the rendering of the data template which again is re-usable.

You now have two re-usable packets of XML that can be applied one-to-many times ontop of an existing Control. If however its instance focused and you don't desire this than an inline syntax is fair game, however should you use to consolidate the UserControl to one line then its really an inline "Usercontrol" problem not so much an overall XAML standard issue (ie route the inbound property to its child HAS-A relationship).

One could though infer that if you use <MyControl Foo.Bar="200" Foo:Class="Foo;mypath.to.Foo"/>or something similar you're instructing the implementer that the attribute for Foo belongs elsewhere to the MyControl class - but - next comes an issue found in IoC world = "Is this a singleton or instance?"

Moreover, how do i use Interfaces vs Instances here... IFoo vs Foo.. without tipping my hand to XAML which is ignorant of .NET / Java / Python etc..