The eXtensible Application Markup Language (XAML) is a declarative language that enables you to initialize objects in XML format. This format enables you to easily visualize a hierarchy of elements while, at the same time, separating content from code. This separation is possible because each XAML element maps to a .NET type. Each attribute within an element corresponds to a property within a .NET type. This concept is probably best illustrated by figure 1.7.
Figure 1.7. Any object that you create in XAML can also be created within code.
The illustration in this figure shows three code equivalents to a segment of XAML. Notice that the TextBlock element in the XAML code corresponds to an initialization statement within the code segments. This initialization occurs because, each time an element is created in XAML, the corresponding .NET type's default constructor is called behind the scenes. Also occurring behind the scenes is the executable code defined within the code-behind files.
1.3.1. Code behind
Much like ASP.NET, XAML pages support the concept of code-behind pages. Code-behind pages enable you to separate code from design by placing the UI-related code in the XAML and the executable code within a linked source file. This relationship between XAML and source code is best exemplified by figure 1.8.
Figure 1.8. The relationship between an XAML file and a code-behind file within a C# project
As this figure illustrates, the XAML code is stored within a .xaml file while the code-behind class definition is stored within a .xaml.cs file. (The extension will vary based upon what language you're using.) In all honesty, the class definition is stored within two files: a file with the .xaml.cs suffix and a file with the .xaml.g.cs suffix, which is automatically created by Visual Studio. The .xaml.g.cs file provides the variable and method declaration for ease of development. In fact, the InitializeComponent method from figure 1.8 is stored within the .xaml.g.cs file. Your coding efforts should take place within the .xaml.cs file though; for this reason, we'll focus on that file.
The XAML file references the code-behind file through the x:Class attribute. This class definition is compiled and stored within an assembly that gets placed within a directory relative to the application called ClientBin. The class definition is primarily used to handle the events triggered through the user interface defined within the corresponding XAML file. As shown in figure 1.8, through the Loaded attribute, you can specify the name of the event-handling method within the XAML code. When using this approach, the compiler expects a method named after the value of the attribute within the code-behind file. You must ensure that the method accepts the correct number and type of parameters.
1.3.2. Namespaces
A namespace provides a way of organizing related objects within a common grouping. These groupings, or namespaces, give you a way to define where the compiler should look for a type. To specify where to look, you reference a namespace within the root element of an XAML file. Snippet 1.1 illustrates the use of two namespaces.
Snippet 1.1. XAML: A basic XAML file referencing two namespaces
As this snippet illustrates, you're permitted to summon multiple namespaces within a single XAML file. When you reference multiple namespaces, each namespace must be uniquely prefaced. For instance, the x prefix in this example is used in association with the http://schemas.microsoft.com/winfx/2006/xaml namespace. At the same time, the http://schemas.microsoft.com/winfx/2006/xaml/presentation namespace doesn't use a prefix.
These two namespaces we just mentioned will be used in almost every Silverlight application you work with or see. These namespaces are generally defined in the following manner and expose these features to your Silverlight applications:
http://schemas.microsoft.com/winfx/2006/xaml/presentation— Provides your applications with the core Silverlight elements. For this reason, this namespace generally omits a prefix, making it the default namespace within the page. This approach enables you to reference elements within this specific namespace without having to include the prefix.
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"— Provides functionality that's common across XAML. It's important to remember that XAML is used by other technologies, such as WPF and Windows Workflow Foundation (WF), all of which need access to common features such as Name, Key, and Class properties.
A tale of two namespaces
In addition to the http://Schemas.microsoft.com/winfx/2006/xaml/presentation namespace, the Silverlight runtime supports http://schemas.micro-soft.com/client/2007 as the default namespace. But, you should use http://schemas.microsoft.com/winfx/2006/xaml/presentation as the default namespace because Visual Studio and Blend recognize this namespace. This namespace also makes it easier to promote your Silverlight applications to WPF applications if you need to at a later point.
In addition to these two commonly used namespaces, Silverlight gives you the flexibility to reference other namespaces including those within your own custom assemblies. When another assembly is referenced, it gets copied into a subdirectory of your Silverlight application called ClientBin. In fact, when you compile your Silverlight application, it itself gets compiled into an assembly that gets placed in this directory. We'll discuss the application model itself a little bit later; for now, in order to reference these assemblies, you need to define a new namespace, which includes a prefix, namespace, and assembly. Snippet 1.2 illustrates this concept.
Snippet 1.2. XAML: This example references a custom assembly called MyAssembly.dll that contains a namespace called MyNamespace. To access the elements within MyNamespace, the my prefix is defined.
The XAML file references the code-behind file through the x:Class attribute. This class definition is compiled and stored within an assembly that gets placed within a directory relative to the application called ClientBin. The class definition is primarily used to handle the events triggered through the user interface defined within the corresponding XAML file. As shown in figure 1.8, through the Loaded attribute, you can specify the name of the event-handling method within the XAML code. When using this approach, the compiler expects a method named after the value of the attribute within the code-behind file. You must ensure that the method accepts the correct number and type of parameters.
1.3.2. Namespaces
A namespace provides a way of organizing related objects within a common grouping. These groupings, or namespaces, give you a way to define where the compiler should look for a type. To specify where to look, you reference a namespace within the root element of an XAML file. Snippet 1.1 illustrates the use of two namespaces.
Snippet 1.1. XAML: A basic XAML file referencing two namespaces
As this snippet illustrates, you're permitted to summon multiple namespaces within a single XAML file. When you reference multiple namespaces, each namespace must be uniquely prefaced. For instance, the x prefix in this example is used in association with the http://schemas.microsoft.com/winfx/2006/xaml namespace. At the same time, the http://schemas.microsoft.com/winfx/2006/xaml/presentation namespace doesn't use a prefix.
These two namespaces we just mentioned will be used in almost every Silverlight application you work with or see. These namespaces are generally defined in the following manner and expose these features to your Silverlight applications:
http://schemas.microsoft.com/winfx/2006/xaml/presentation— Provides your applications with the core Silverlight elements. For this reason, this namespace generally omits a prefix, making it the default namespace within the page. This approach enables you to reference elements within this specific namespace without having to include the prefix.
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"— Provides functionality that's common across XAML. It's important to remember that XAML is used by other technologies, such as WPF and Windows Workflow Foundation (WF), all of which need access to common features such as Name, Key, and Class properties.
A tale of two namespaces
In addition to the http://Schemas.microsoft.com/winfx/2006/xaml/presentation namespace, the Silverlight runtime supports http://schemas.micro-soft.com/client/2007 as the default namespace. But, you should use http://schemas.microsoft.com/winfx/2006/xaml/presentation as the default namespace because Visual Studio and Blend recognize this namespace. This namespace also makes it easier to promote your Silverlight applications to WPF applications if you need to at a later point.
In addition to these two commonly used namespaces, Silverlight gives you the flexibility to reference other namespaces including those within your own custom assemblies. When another assembly is referenced, it gets copied into a subdirectory of your Silverlight application called ClientBin. In fact, when you compile your Silverlight application, it itself gets compiled into an assembly that gets placed in this directory. We'll discuss the application model itself a little bit later; for now, in order to reference these assemblies, you need to define a new namespace, which includes a prefix, namespace, and assembly. Snippet 1.2 illustrates this concept.
Snippet 1.2. XAML: This example references a custom assembly called MyAssembly.dll that contains a namespace called MyNamespace. To access the elements within MyNamespace, the my prefix is defined.
As this snippet illustrates, referencing other elements, including custom elements, only requires you to provide a couple more details.
1.3.3. Compound properties
Although the illustration in figure 1.6 shows the relationship between XAML and .NET types and properties, we did omit one detail pertaining to properties. Properties within XAML may consist of elements significantly more complex and detailed than primitive types. For instance, the XAML in snippet 1.3 uses another kind of .NET object, called a LinearGradientBrush, to define the background of a Grid.
Snippet 1.3. XAML: A Grid with a gradient background
A compound property enables you to use the syntax of TypeName.PropertyName within an element to define more complex items within an element. This powerful feature gives you the ability to easily see the hierarchy of an object structure. In addition, it gives you a significant amount of flexibility when you're creating control templates, a topic we'll discuss . But first, another kind of property is as equally important as the compound property.
1.3.4. Attached properties
An attached property is a property specified within an element other than the element that references it. Although this seems like a mouthful, it really isn't. You can easily recognize an attached property by its consistent syntax of Attached-Element.PropertyName. These special attributes are generally used within the context of layout panels, which we discuss .
As an example, let's pretend you need to define a Rectangle within a Canvas. This Rectangle will have an offset of 10 pixels from the top and 10 pixels from the left of the Canvas. The subject (Rectangle) is presented relative to the parent (Canvas), so, as snippet 1.4 shows, the subject is attached to the parent.
Snippet 1.4. XAML: An example showing the use of two attached properties in action
No comments:
Post a Comment