The path to reusable XAML

08-23-2007 8:25 AM |

If you have not read this article;

http://blogs.microsoft.co.il/blogs/justinangel/archive/2007/08/14/Silverlight-Controls-_2D00_-The-path-to-reusable-XAML.aspx

it is a must read. Basically he shows how to create Silverlight code that follows proper OO design and XAML that you can edit in Expression Blend.

Re: The path to reusable XAML

08-25-2007 10:35 AM |

Hey Michael,

 Thanks for all the kind words. It was extremely importent for me to write this article as a gate-way for developers who really wanted to get some work done with Silverlight. So I'm very glad to know you've found it helpful!  

After I published that article Tim heuer did two great screen-casts on the same subject. Knowing Tim, they're extremely good screen-casts.
http://channel9.msdn.com/ShowPost.aspx?PostID=335728 - Silverlight: Implementing User Controls in 1.1
http://channel9.msdn.com/ShowPost.aspx?PostID=335556 - Silverlight: Implementing User Controls in 1.0
Code available at his blog: http://timheuer.com/blog/ 

Re: The path to reusable XAML

08-26-2007 3:20 PM |

The Tim Heuer screen cast is first rate. It's amazing how good he is. His screen cast explains how to use reusable XAML your article explains WHY. The distinction is important. I think people need to understand why you should code your way.

ASP.NET forces you to use an event driven model. If you try to create a "Response.Write" application you discover that things like the buttons wont work. But, with Silverlight you have the option to create "code spaghetti" and people will start doing it.

I almost started doing it myself. Thank God you stopped me :)

Re: The path to reusable XAML

08-27-2007 5:56 PM |

I noticed that Tim did not use replace to replace "Name=\"" (to prevent name collisions) is it because of the way he added the controls to the page? Which method is better?

Re: The path to reusable XAML

08-28-2007 10:26 AM |

Michael,

 Those are two different ways of dealing with "x:Name" collisions, each with some minor benefits & downsides.

Tim suggests (and wisely so) to use private namescopes. Here's a great article on that subject:
http://nerddawg.blogspot.com/2007/05/namescopes-in-silverlight.html

Let's say we've got a "<rectangle x:Name="myRect" />" in our main Page canvas and In our User Control.

What private namescopes actually mean is that name collisions can't happen between various namescope where each control is it's own namescope.
So if both mainCanvas.myRect and myUserControl.myRect can exist on the same page, because they're in different namescopes.
We enable the private namescope feature other by specifying createFromXaml("...",true) (Javascript), InitializeFromXaml("...") or XamlLoader.Load("...", true).

So, while private namescopes help us avoid name collisions, they do present us with one restriction - you can't use findName on any element outside your namescope. So the child doesn't know the elements inside the parent, and the parent doesn't know the elements inside the child. 
mainCanvas.FindName("userControlRect") - nothing
pageCanvas.FindName("pageRect") - nothing

While this is good OO design and forces our two controls two talk directly with each other, there are occasions where we'd like to have FindName and won't have Namescope collisions. This is where the approach I've implemented comes in, we're canceling out private namescopes and using our own "namescope" system which in this case is based on XAML string replacement (and In the future could be based on Initializing the XAML in a private namescope, changing it based on the parent ID and making then canceling the private namescope).

It's not a big issue, but as Silverlight Control development only have a few built-in features, I wanted to make sure FindName will still be available throughout the control hierarchy.  

Re: The path to reusable XAML

08-28-2007 11:02 AM |

What I have done in the control framework I created is to prefix the name of each child element with the name of the control itself.  So each new custom control goes on it's own Canvas with it's unique name, onto which I then add all my elements.  I also set the unique name as a TAG value on my canvas, and within the custom control I can then retrieve this and use it in findName expressions to know which instance of a control I am using.

This seems much more natural, and similar to the way we name ASP.Net controls.

- Dave

Re: The path to reusable XAML

08-28-2007 11:25 AM |

Dave,

That's a great idea, and the one I've also implemented. The article mentions this option as the end result for a name hierachy (like ASP.Net has).

"The ID could also be determined by a control hierachy like ASP.Net does, but this is outside the scope of this already full article. "

If you blog about it, they will come :)

Re: Re: The path to reusable XAML

08-28-2007 12:55 PM |

Thank you for explaining this. Also I read the article at the link and it also clearly explains the issue.

As to the .FindName, to me it seems ok that I cannot find a control unless I use .FindName on the containing control. For example, if I have 5 buttons (that I created using Tim's method) on the page and I want to change the text on one of them I should have to do a .FindName on the root canvas to get the button then do a .FindName on the button to get the textbox so I can change it.

Am I understanding this correctly? IS there other issues that I'm not aware of? I'm just trying to learn. Thanks