- Shopping Bag ( 0 items )
Starting with a guide to the basic principles of database design, we then examine how to query databases and how to access their data - both in Windows applications and remotely using the Internet and Web Services. Every new concept is explained thoroughly with Try It Out examples, plenty of code samples, and end-of-chapter questions to test you.
This book covers:
In this chapter, we'll be looking at the essential nature of XML and see a few of the basic tools that are provided by .NET and ADO.NET for the creation and manipulation of XML data.
XML is one of those curious technologies that, while it seems scary to a newcomer, the principles are actually very easy to grasp. (Building an end-to-end solution using XML throughout can get a little tricky, however!) The classes available to us in the .NET Framework provide ways to read, write, and explore XML-formatted data very easily.
Despite its name, XML is probably best thought of not as a "language", but rather as a set of rules for defining markup languages. In order for applications to exchange data, the data has to be "marked up" in some way. This marking up allows an application receiving the data to make sense of it and use it in a useful manner. For example, if I give you a bit of data like this:
…how do we know what that data is? However, if I give you a little more information about the data, like this:
My Dog's Name: Disraeli
…then, using common sense, we can all understand what that bit of data represents. In the latter case, I've "marked up" the data. By using the English language, English-speaking readers at least can use the set of common sense rules that we all carry around in our heads to determine what I'm trying to say. XML is a "meta language" or, in other words, is self-describing – it gives the data and the rules to follow to determine what the data is.
As we said, XML is not a language but rather a set of standards and rules for creating your own markup languages. One of these rules is that XML documents must be well-formed. There are over a hundred rules for creating a well-formed XML document, but here are the three basic ones (luckily, the other ones are things you're unlikely to do anyway and so aren't of much importance):
...because ElementOne is closed before ElementTwo is closed.
Those of you who have seen HTML code will notice that the XML files look very similar. That's because they both share a common ancestor. Standard Generalized Markup Language, or SGML, was the inspiration for both.
XML files work on the concept of tags and elements. A tag can either be a "start tag" or an "end tag" (or "both" – sometimes start and end tags are combined, but we'll see this later). Here's an example of a start tag:
…and here's an example of an end tag:
You can see that both kinds of tags start with a less-than sign and end with a greater-than sign. This is how tags are delimited. The name of the tag appears between these two signs, and, in this example, the name of the tag is ShipCity. The difference between a start tag and an end tag is that, on an end tag, the name is prefixed with a forward-slash character.
Together, a start tag and an end tag make an element. The text between the two tags is the data that belongs to the tag. For example:
In this case, we have an element called ShipCity; the value of that element is Albuquerque.
Here are the elements that make up order 11077 as shown in our XML document:
Now life starts to get interesting. Elements can contain other elements. In this case, we have a start tag called Order and an end tag called Order.
<Order> <OrderID>11077</OrderID> <CustomerID>RATTC</CustomerID> <EmployeeID>1</EmployeeID> <OrderDate>1998-05-06T00:00:00.0000000+01:00</OrderDate> <RequiredDate>1998-06-03T00:00:00.0000000+01:00</RequiredDate> <ShipVia>2</ShipVia> <Freight>8.53</Freight> <ShipName>Rattlesnake Canyon Grocery</ShipName> <ShipAddress>2817 Milton Dr.</ShipAddress> <ShipCity>Albuquerque</ShipCity> <ShipRegion>NM</ShipRegion> <ShipPostalCode>87110</ShipPostalCode> <ShipCountry>USA</ShipCountry> </Order>
Notice how the data that's contained within the Order element is a bunch of other elements. XML is hierarchical in nature, which means that the Order element contains a set of thirteen child elements, and each of those thirteen child elements represents one column from one particular row. The upshot of this is that if we have an Order element, we can drill down into its child elements to learn everything about the Order that we could possibly need to know.
If you look further into the document, you'll notice that each of the two Order elements is contained within a master Order element. (I've omitted some elements here for clarity.)
<Orders> <Order> … </Order> <Order> … </Order> </Orders>
Again, this means that, if we have an Orders element, we can assume that we have a list of orders contained within. We also know that each order is encapsulated in its own element called Order. As we stated earlier, every XML document must have exactly one top-level element, called the root element. In this case, we do indeed have only one top-level element: Orders. If we omitted this element, the file would not be well-formed. For example, here's the same document again but without the single top-level element:
<Order> … </Order> <Order> … </Order>
In this case, the document has two top-level elements. Under the rules of XML, this document is not well-formed – therefore it cannot be used.
Attributes have the form of a parameter="value" pair, and sit within the opening tag of an element. We can have as many attributes as we like, and store any data that we like in them:
<OrderID IsId="True" AnotherAttribute="92384">11077</OrderID>
That's the basis behind XML. At this level, XML is mostly common sense and, I'm confident, pretty easy to understand. Because of this, what we'll do next is build the app that produces this output. This will bring the potentially fuzzy points of our discussion so far into sharp focus.
1. Using Visual Studio .NET, create a new Visual Basic | Windows Application project and call it Order Export.
2. When the Designer for Form1 appears, drag on a DataGrid control and a couple of Buttons, like this:
3. Change the properties for the controls in the Properties window, as shown below:
4. Using the toolbox, drag on a new SaveFileDialog control. Change its Name property to dlgSaveFile.
That's the basic design of the form finished. Now we just need to add some business logic functionality.