Namespaces are common in the developer and markup world. They exist in coding APIs and in XML files. This video explores XML namespaces and looks at the default namespaces for a WPF XAML file.
- [Narrator] Namespaces are common in the developer and mark up world. They exist in coding APIs and in XML files. In this video, I'll explore XML namespaces and look at the default namespaces for a wpf XAML file. I'll start with a quick tour of the general principles of namespaces. If you know these details, I'll only take a minute to go over the basics. Rule number one for namespaces is that a namespace is a container for named items, and rule number two is that all the named items that go in that namespace must be unique.
For an example, I've got a documents namespace, and I've put in three names, Title, Author and PageCount. I would not be allowed to take the Title name and put it in the namespace a second time. That would be confusing for a parser to determine the differences so it's not allowed. But it is allowed if I have a second namespace. Here I've got the movies namespace, and it's got Title, Producer, and GrossSales. So Title is the same in both these namespaces but because they're in separate namespaces it's okay. If I put both of these in the same XML file there's enough differences so that we can find what it means to be Title, Movies title or Documents title.
Somebody has to decide these names, and also here's a rule that says each namespace has to have a unique name. Let's look at this example Documents. What if I were to rename this as Documents, and put both these namespaces in the same XML file? Now, again, we have a problem. The parser wouldn't know how to deal with this, so you have to have unique names for each namespace. As I said, somebody has to decide these names, somebody has to name the namespace, someone also has to name the unique items that go in it, and this is called the namespace authority.
On simple projects, say a sole developer working alone, you would be the namespace authority. On something bigger than that, let's say XHTML specification, there was a committee at the W3C that spent months deciding which element names go in this specification. So now that we know the basics let's look at the implementation in XML in a wpf project. I've opened this DefaultWindow.xaml file. When you create this file Microsoft adds a number of XML namespaces to this document.
You can see them at the top here, there's five of them, and in XML the way you do namespaces is by doing xmlns, and if you have more than one namespace declaration you have to use what's called a prefix. For the second declaration Microsoft uses the x prefix, for the third one they use the d prefix and so on. Microsoft's the naming authority, so they're the ones that came up with the unique URL here, and in XML you use a URI to uniquely name the namespace. You see and since Microsoft's the naming authority they use their domain name, schemas.microsoft.com and then some sort of unique string on the end of that.
You can see that there are three of them here, they all have the microsoft.com domain in it. This first namespace does not have to have a prefix, it could, but it doesn't have to have one, and this makes my life easier, and your life easier because now when I want to use the window, or the grid, or the button, I don't have to use a prefix. Imagine what would happen if Microsoft had come in here and put a prefix on this, like wpf. Now in order to work with the window element you would have to type in wpf: to resolve this, and the same for this grid, and the same for this button.
The disadvantages of doing this is it makes the XML file larger, because there's more characters in it, and it's harder to read, there's just more stuff to look through when you're looking at your XML. We'll undo my actions and go back to defaults, and so that's why Microsoft uses this default namespace to alias that to all the common wpf.net objects. In order to work with the items in this namespace I have to use x:. So let's say I want to go to this grid, and I want to set an attribute here, I type in x:, that drills me in to that namespace and Visual Studio gives me opportunities to look at some of the unique names that are inside that namespace, so name, Uid, and FieldModifier are available.
Pick this one and that resolves. This also works at the element level. You can see some of the unique names that are inside here that are listed as elements. So Code, Array, Null. Those are examples of items that are specifically included in this namespace. Now that you have a better understanding of XAML namespace declarations and the namespace prefixes and how they're used, let's look at the concept of namespace mapping. Here's that idea here is that this window class and this grid class and this button class, those are wpf objects, but they are somehow aliased to these XML elements.
How's that work? That's the topic of the next movie.
- What is XAML?
- What frameworks use XAML?
- Working with XAML and Visual Studio
- Exploring XAML namespaces
- Instantiating objects
- Subscribing to events
- Using XAML in Windows Presentation Foundations, Universal Windows, and more