Documente online.
Zona de administrare documente. Fisierele tale
Am uitat parola x Creaza cont nou
 HomeExploreaza
upload
Upload




WORKING WITH XML

computers


Lesson

WORKING WITH XML

In this video we will talk about XML files. First we will talk about what they are and what they look like. We will briefly talk about access D files, or rather XML schema document files, and then we will show how to open up an XML file from our hard drive, and read through the data in the file using the .net framework in C#.



XML stands for Extensible Markup Language, and it is very similar to HTML in its use of tags. However where HTML contains both unstructured information and how to format that information through the use of tags, XML contains structured information, but contains no tags that indicate how the data should be formatted and displayed to the user. And the reason for this is that XML has a much different purpose than HTML does. XML is an easy way to store or transfer small sets of organized data between computers or between software. Now the need for this might not be readily apparent. But consider that there are so many different software vendors that each has their own format to save their data in, and that is sometimes referred to as Proprietary Data Formats. Transferring data between those software programs could be eased by a common language, or rather a common way of representing data that is easily readable both by humans and computers. Now the format is not as efficient for storing or retrieving or searching through the data as the other more proprietary formats are, but it definitely has some benefits insomuch that it is an open format. It is very portable. Now the reason why we're examining XML is because there are a lot of applications for it. When we were looking at the data access D file in the previous lesson, I said that it defines the structure of an XML file. However, what might not have been very apparent was why it was used to also defin 242j96c e a dataset.

[Start: 00:00:00 & End: 00:02:02]

Well the reason is because the dataset is managed internally by ADO.NET as an XML document. So in this manner, it makes it really easy to allow your user to retrieve data from the database in the application. Then the user can disconnect from the network or from the internet, and still be able to make changes to the data, to access the data. The XML then would just be saved from memory into a file in the user's hard drive, and then retrieved if there is no network connection. And then later on, once they connect back to a network, all the changes that the user made can be saved back into the original data source into the database. Or it could be important to know the program that also knows how to speak XML, and there are really a lot of creative ways that you can use this functionality within your applications. XML is also used for syndicated RSS feeds, which we're going to make use of in the last five videos of this lesson series. So I wanted you to become familiar with some of the basic concepts and how to navigate through the data in an XML document in C#, and display it on the screen, and manipulate it and so on.

Let's take a look at a simple example of what an XML file looks like by creating a new application, which I have already taken the liberty of doing called lesson 10, and in this lesson 10 project, what I want to do is select the "add new item" icon from the toolbar, and then select "XML file," and I'm going to change the name of this from XML file 1 to cars.xml, and then select the "add" button. So then it creates a new file cars.xml in my project, and it opens up the file into the main area of my designer. So this creates for us a blank XML file. It does have one line of code at the very top, and this is the declaration of the XML file, and it defines the version of XML that is going to be used.

[Start: 00:02:02 & End: 00:04:04]

Now the specification for XML is constantly being reviewed and updated in minor ways that are really not important to know right now. But this little bit of information here is really for applications so that the application can know what version the document should conform to. Now the second part of this definition statement is the encoding style, which defines what set of characters to expect the document to be encoded in. Let's not worry too much about this for now. Instead, let's try creating something interesting. So what I'm going to do is just go to the next line here, and start typing the word "carlot." Notice that I used an open bracket to start, and then I'm going to use a close bracket, and when I do the IDE automatically inserted a second tag of the same name, but it also has a forward slash. Now let me set up this example so you can understand what I'm going to try to do, or at least the philosophy of the example. I have created this fictitious scenario of a carlot, and I'm creating an XML document that contains the details of the cars that I have for sale on my carlot. Now I want to exchange this list of cars with other car dealers in my area. Now the thought is that I would give another car dealer a commission on any car that he sells from my car inventory. So if he does not have the car that his customer is looking for, he can search a database that's populated by the various car dealerships around town, and see if anybody else has that car. Now if I'm a dealer on the other side of town, the benefit to me is that I'm able to sell more cars to customers than I may not have had otherwise been able to reach. So this file could be loaded into whatever software each dealership uses for performing their own searches. Or perhaps this document could be crawled by some search engine out on the internet that displays cars over the web to people who are looking for car deals online. So whatever the case might be, I have got this concept of a carlot, and the first thing that I have created was an element called carlot.

[Start: 00:04:04 & End: 00:06:07]

This is called the root element of the XML document. XML documents have to contain one element that encloses all the other elements within the body of the XML document. So this is called the root or the root element or the root node. And so sometimes I'm going to refer to the word node, and system.xml in the .net framework classes, they use the word node as well. It is just another word for element, and I'm going to use these interchangeably whenever I talk, so you know. So I'm going to create a single car element within the carlot root. And the way I do that, go over here, and do an open tag, type in the word car, and then a close tag. And notice that the IDE again completes the creation of the tag by creating an ending tag so you have a begin and then end. And let me do another one as well. So now I have two children elements within the parent element of carlot. Now the two car elements are considered to be sibling elements. And the carlot tag, which encloses those two sibling car elements, is considered to be their parent. So think in terms of familial relationships when you are working with hierarchies of XML data.

Each element can contain other sub-elements, which in turn can contain other sub-elements and so on. So how you structure the element hierarchy is really up to you, and what your particular needs are. So elements can contain other elements, or elements can contain data. Let me illustrate this.

[Start: 00:06:07 & End: 00:08:00]

So in this case, I have created another element called "make," and it contains information in this case the make of the car, which I have defined between the two tags, the begin make tag and the end make tag as Oldsmobile. So basically you see here again that the car element contains nodes, but the make element contains text. So an element can contain either other elements or can contain text or some value. It can contain one or the other, but it cannot contain both. Or an element can contain neither, as in the case that I'm going to do right now, in the case of price. So you can see in this example that this is not very useful because it does not contain elements, it does not contain a value. So what is the real purpose of this? Well, by itself, there is no real purpose. But elements can also contain something called an "attribute." So in this case, what I could do here is something like value equals 2500. So we have got an attribute called value, and the value of the property value or the attribute value is 2500. We could also put that here instead, so price equals 2500. And I can just delete this. So attributes are information that is encoded directly in the element definition. Now when you use elements versus when you use attributes, that is completely up to you, which brings us to the next point.

In XML, you define the structure of the document, and you define the tag name, or rather the element names, and you define the attribute names, anything you want. The tag names should be descriptive of the type of data that is going to be stored in the element because this makes the XML document self-describing and easy to read by humans as well as computers.

[Start: 00:08:00 & End: 00:10:11]

So for the most part, this is all pretty much freeform. You can do whatever you want here. However, the structure that you choose should be consistent and follow some pattern. It would not make a whole lot of sense to have one car defined like this: We have got here model, and call this Cutlass Supreme, and year . Of course I have got to spell correctly. And then have another car defined like this: Now the two definitions for the car may convey the same thing to us as humans because we can equate a company with the make, the style with the model and the year that it was built with the year tag. But a computer is not going to be able to make that distinction because it does not understand the context of what we're talking about. So there is nothing wrong with choosing either one of these ways to describe a car. You can pick either one. But you just need to pick one, and stick with it. Now the way you define the structure of an XML document and stick to it programmatically is through the use of an access D file or rather the XML schema document. This document defines the hierarchy and the structure and the data types that are used in your XML document.

[Start: 00:10:11 & End: 00:12:05]

Then it is incumbent on your XML document to make sure that it follows this definition exactly, and if does not follow the definition exactly, then your application will have unpredictable results. The application that depends on this XML file will probably fail because it is expecting certain words to be used or certain tag names to be used, and structure the to be in a certain format, there to be, you know, the child of the carlot should be the car and the child of car should be the make, model and year and so on. If you do not follow this, then your application will probably fail. Now we're not going to build an XML document for this example, and I'm not going to show how to associate an XML document with a corresponding XSD document, because it's really beyond the scope of this lesson. The only reason I bring it up is because you saw an XSD document in the previous lesson. Now you kind of understand the relationship between the two. And then also so that you understand that while an XML document is free form, that you do have some flexibility there, really if you want to enforce a certain hierarchy of data so that it can be relied on to be programmed against use in a programming scenario, then you are going to need to define an XSD document or be very disciplined to type things in exactly the way that they should appear each and every time. The XSD document is then is just a way to enforce that, to make sure that you do not accidentally name something incorrectly or you use improper styling choices in how you indent or imbed the various elements. So what we're talking about here is the need for consistency. This is called "being valid". Valid documents follow the schema that they are associated with that defines the structure exactly. So if a document is considered valid, that means that the XML, the structure of the XML, the placement of the tags and everything follow the way that they were defined in an XML schema document.

[Start: 00:12:05 & End: 00:14:08]

Now there is another test that makes sure that the XML document follows the rules of XML, and that is whether or not the document is considered to be well-formed. A well-formed XML document has the tags in the right spots, it is not missing any ending tags, they are not transposed so that you have this tag outside of here. You can see that when I do that, I get these red squiggly lines. That is because the document is no longer considered to be well-formed. The embedding is all messed up. Now when I move this back, we're able to get it back into a correct state, a well-formed state. So the difference between being well-formed and being valid is very subtle. A valid document must be well-formed. But a well-formed document does not necessarily have to be valid. This document is well-formed, but it is not necessarily valid because I have used two different ways defining what a car looks like. So I'm going to correct that right now by just deleting this from our document. In fact, what I'm going to do is just paste in a new set of XML here that I created earlier for my carlot. So I have got the concept of a make, model, and elapsed miles for both an Oldsmobile Cutlass Supreme and a Chevrolet Camero. So I currently have two cars on my carlot. This is what my XML file is going to look like. If you want to follow along, please pause the video here and create an XML document just like I did a moment ago that looks exactly like this.

The next thing I want to do with this example is show you how to access this XML document that we created through the use of C# and the system.xmlclass namespace in the .net framework.

[Start: 00:14:08 & End: 00:16:00]

So what I'm going to do here is add a button onto my form, and I'm just going to create a real cheesy example here, just so we can fully exercise how this thing works. I'm going to add a bunch of label controls, just label 1 through we'll use each of these in just a moment. In fact I'm going to pin this down. Now this isn't going to be a terribly practical example. But it will show you how to open up an XML document off of the hard drive, and then how to display and navigate through the XML document using the system.xml name spaces. Let's close that down for now. Let's hit "save." Now the way that you open up an XML document and begin to work with it, may not be so straightforward. You actually have to take it in three different steps. The first step is to open up the file and read it from the hard drive into the computer's memory. And you do this through the use of the system.io.streamreader class. Once the file is read in the memory, then it has to be converted into XML. And so will use a different class called the XML text reader from our system.xmlnamespace. Now finally, after it has been parsed by the XML text reader, and parsed just means to look through it and make sure that it is well-formed, that it is actually an XML document, and does some other little reading and optimization reading from within. We're going need to read it into a format that it can be worked with. And so we will use an XML document object in order to do that. So let's just double-click our button, and I'm going to paste in some code. So first of all, we're using that streamreader class that we talked about, system.io.streamreader. I'm going to call SR equals new system.io.streamreader we're going to pass in the constructor. We're going to pass in the location of the cars that XML file.

[Start: 00:16:00 & End: 00:18:11]

Now the use of this little "at" symbol here just means that we're going look in our current directory for the project. If we did not use this, then it would look elsewhere in the hard drive for that file. And so it would not probably find it, and we get an exception right here. Now clearly, for wanting to create a more stable application, we would want to make this more flexible and not hardcode the file name. But, for our purposes and just getting started, this will work just fine.

So the next step then is to take that data that is in memory in the computer, and turn it into XML. The way we do that is through the use of the system.xml.xmltextreader. So we create a new instance of that, and we pass in as an argument in the constructor the streamreader object that we just created in the previous line of code. So now that we have determined that this is indeed XML, and has been parsed correctly, we need to put it in a format that we can work with it, to look through it, and navigate through it, and so on; and the way we do that is to put it into an XML document. So you can see here we have created a new XML document carlot newsystem.xmldocument. So now we have our carlot.doc object that we can use to parse through and work with. We need one other step here, and that is to, just creating it is not enough, we have to pass in a reference to the text reader, the XML text reader. So we'll do carlot.doc, our carlot.doc.load, and we will pass in the XML text reader. And now it is loaded into our carlot.object. One of the first things that we can do, now that we have the XML parsed off for us, is to use the inner text property in order to display the entire contents of our documents. So let's do this: carlot.intertext. Let's set that equal to label 1.text=text. Let's save this and then run our application, and make sure that it works up to this point.

[Start: 00:18:11 & End: 00:20:28]

And when we do, notice that we get a file not found exception. Basically whenever our application is running into debug mode, a copy of the cars that XML file needs to be in the bin directory / debug directory. So let's do that right now. Let's copy our cars file, and we go to our Windows explorer, Visual Studio 2005 projects, lesson 10, and we will just continue going down until find the file. It looks like we have lost it somewhere here and so I'm going to go back to the car, to the lesson 10 directory, copy and then paste it into the debug directory. So let's go ahead, and run the application again. Now we can see that we have Oldsmobile Cutlass Supreme 5000 Chevrolet, Camero 60,000. The data is not very well formatted. It is just all run together. Notice that we do not have any tags listed whenever we're using the inner text property. And quite honestly, this isn't very useful in this current format. So what we will need to do is navigate to one of the child nodes of our root element and start grabbing information from it. So let's do this: I'm going to paste in some comments so we can remember what we want here, and we're going to set the value of label 2.text equal to carlotdoc.firstchild.innertext, and to make it more obvious what this is, let's do this: So here we're going to grab the first child node, and display its inner text. Again the inner text would be just what is contained within that first child node. So let's run this. Select our button. So the first child node is actually our XML definition version 1.0 encoding UTF8.

[Start: 00:20:28 & End: 00:23:05]

Not exactly what we're looking for. So let's continue moving on. Let's use some navigation in order to get from the first child to the next child. There is a bunch of different ways we can go about this. And this might not be most efficient, but what I want to do is to show you how you can navigate through your document. So we have our second child node. So we'll do this: carlot.docfirstchild.nextsibling. So the next sibling in line should be the carlot root node, hopefully. So let's do this inner text. And let's save it, and let's run it. So our second child node would contain then the inner text. Notice that the second child node's inner text is the exact same as the inner text for the entire document, so that inner text on the document object will help us get directly to the information that we're looking for, and help us avoid any of the definition-type information at the top of the document. But we still get access to it by using the first child method of our document object. So let's move on.

Next thing I'm going to do is just get a reference to the carlot object. So let's do this: system.xml.xmlnodecarlot=carlotdoc.firstchild.nextsibling. So now I'm working just with the carlot, and I can do something like this. Let's populate label4.text. We'll just grab the inner text of carlot, then we will go label 5.text=the first child of carlot. So what do you think I will do for that? Carlot.firstchild.intertext, and then let's just get kind of funny here. Label6.text=the first child of the first child of carlot. So what do you suppose that would be?

[Start: 00:23:05 & End: 00:26:10]

Carlot.firstchild.firstchild.intertext. So let's run this now, and look at the fourth, fifth, and sixth labels. So now that we have a reference to carlot, we did the inner text, which would be just exactly like what we saw in the previous example and the first example. And now we're grabbing the first child of carlot, which would be that Oldsmobile Cutlass Supreme that we created, and now what we want to do is just grab the first sub-element or the first child of that Oldsmobile Supreme, which allows us to grab the word "Oldsmobile."

Now quite honestly, this is not a very efficient way to go through an XML document, but I just wanted to show you the ability for you to navigate from the first child to the next sibling, and so on in order to go through each node, and find what you are looking for with an XML document. So this is using more of a parent-child-sibling metaphor. It is one good way to navigate through an XML document, but it can be tedious sometimes, and problematic because the document may not be formed exactly the way that your program might anticipate it. It still might be well-formed, it still might be valid, but just different than what your application is expecting.

So another way you use to utilize an XML document is through the use of an x-path expression. Now x-path is a companion technology to XML that allows you to search through the XML document to find exactly what you are looking for. So I'm going to paste in an example here, and not type the whole thing out. Let's talk about this. First of all, I'm going to grab a node list, an XML node list that I'm calling carlot items, and I'm going to use my carlot doc that I created earlier, and use the select nodes method in order to find all the nodes of type carlot/car. So what do you suppose this will return back to me?

[Start: 00:26:10 & End: 00:28:26]

It will return two nodes, one for Oldsmobile and one for the Chevy, that allow me then to work with just those two nodes. I do not have to go, you know, first sibling, next sibling and so on. I'm able to search directly, and bring back all the nodes that match this criteria that I have created. You can see in the previous example that I commented out that I'm able to find all of the nodes that match carlot. Now that would only return back one node for the carlot node. It would not make a whole lot of sense to use that. But this allows me go one level deeper, and I could even search one level deeper, and return all the nodes that, for example, match that sequence, carlotcarmake. We're not going to do that for right now.

The next line of code is to actually grab one node, which I'm calling the make, and what I'm doing now is working with that list of items that were retuned in the previous line of code. So I had two items, the Oldsmobile and the Chevy. I'm going to work with the first item, item sub-zero, and I'm going to select a single node that is a child of either the first or second car. I'm going to grab that node that defines the make of the car. So what would you expect this line of code to return? Let's run it and find out. You can see here that it returned the word "Oldsmobile." Now why did it do that? Because again, we first of all grabbed all of the nodes that matched carlotcar, which would bring back this and this. Then we worked with the zero for the first item within that list, which would be this one, and we said, "find the element within car, called make, and return the value," which was Oldsmobile.

[Start: 00:28:26 & End: 00:30:28]

So I hope that you can see two things from this lesson. First of all, that there is nothing really magical about XML files. It is just text. You can create any format you want for it, or use any keywords that you want to use. You just need to make sure that you go about in a consistent way whenever you are defining the data that is within XML file. And then the second thing is that it is very easy to navigate through the XML document in .net. You can either go about it from what I called the parent-child-sibling metaphor where we're able to find the parent or the child or the next child or the next child, and its children and so on, and think of it in those terms. Or to use an x path expression where you are searching for elements within your XML document that match a certain pattern based on the names of the tags that you have used.

Now if this does not make complete and total sense to you, watch the video again. Do not make too much out of it. It is a very easy concept, and although there are more things that we can add to your knowledge, this will get us as far as we need to go for the example that we're going to create in the next five lessons at the very end of this series of lessons. Over time, you can add more to your knowledge. So do not be intimidated by this. It is a very easy concept.

So if you enjoy this video, please visit www.learnvisualstudio.net to download and watch over 500 videos just like this one aimed at all skill levels on many different topics related to C#, visualbasic.NET, ASP.NET and more. Thank you.

[Start: 00:30:28 & End: 00:32:15]


Document Info


Accesari: 1670
Apreciat: hand-up

Comenteaza documentul:

Nu esti inregistrat
Trebuie sa fii utilizator inregistrat pentru a putea comenta


Creaza cont nou

A fost util?

Daca documentul a fost util si crezi ca merita
sa adaugi un link catre el la tine in site


in pagina web a site-ului tau.




eCoduri.com - coduri postale, contabile, CAEN sau bancare

Politica de confidentialitate | Termenii si conditii de utilizare




Copyright © Contact (SCRIGROUP Int. 2024 )