D'Arcy from Winnipeg
Solution Architecture, Business & Entrepreneurship, Microsoft, and Adoption

Silverlight – Embedding Objects In XAML

Saturday, April 11, 2009 3:42 PM

At my recent TCCC talk, someone had a question about storing data in objects within XAML. This is actually relatively easy to do, but there are some limitations to it. Let’s walk through a scenario.

I’m creating an image viewer so that I can browse my collection of David Hasselhoff pictures. I first create an object to hold the title, comments, and the name of the image:

image

Next I whip up the interface: two TextBlocks and an image control. The UI isn’t the focus of what we’re doing so just envision it happening in your head.

Now I want to test my UI out, but without having to write any code behind stuff just yet. I want to see what my UI will look like without me having to enter sample text in the control properties themselves or creating an object behind the scenes. What I can do is define the object within the XAML instead.

Step 1 is to add a definition in my UserControl tag.

image

Note the line starting with xmlns:ucr=… What this line does is associate the ucr abbreviation to my project’s namespace (I just picked ucr for User Control Reference…naming is totally up to you).

Step 2 is to actually specify the object. We add a UserControl.Resources tag within the UserControl node, and then specify the type of object we’re defining, prefixing it with the namespace abbreviation we declared earlier. We then give it a specific name and define the values for the object’s properties.

image

Step 3 is to set up the control binding. Notice that not only are we specifying the property to bind to, we’re also specifying the source of the binding as a static resource and providing the name of the static resource.

image

Now when we run our app, we can see how it looks with our test data…

image

The same process can be applied at a project level by moving the object resource into your App.xaml instead.

image

There is a problem with the two approaches above though. Because we’re specifying the source within the bindings of the control’s, simply overriding the containing grid’s DataContext won’t overwrite the source; those controls are forever hard coded to look for a static resource.

Luckily, we can access our static resources from code and clean up our control binding so that its not tied to a specific source. Our controls now look like this…

image

And in our code we can do either of the following, depending on whether we’re getting a local resource from our user control or one we’ve stored in the App.xaml file…

image

Ok, so why would you ever want to use this? It’s static, it requires you to manually change the data if it ever needs to be changed, and retrieving the values from the Application or UserControl resources uses hard-coded string values.

For one, this is great for mocking up test data to see how your UI will look without having to change the control properties themselves. Instead of typing in text into a TextArea’s text property, you just modify the local resource object instead. Much cleaner and easier to work with UI test data.

Another possible use is for default values. In the case of my Hoff Picture Browser, what if I wasn’t able to retrieve data from the database? I could enter *default* text into my TextArea controls so that they’re already in a worst case scenario mode, but I’d rather not have to build that into my UI. Instead, my code can determine that I can’t connect to the database and switch to binding my controls to an object stored locally that has default values like an “I’m sorry, but no data is available message” or something like that.

I’m sure there are other uses as well, these are just a couple. I would also suggest that if you’re going to use static resources in the way I just described that you do what us ASP.NET devs have done with Session variables: wrap them within a method so that you only have to write the hard-coded resource name once and not all over your project.

Questions, Comments, Thoughts…let me know!

D




Feedback

No comments posted yet.


Post a comment