Por: John Kaster
Resumo: John K talks with Mark Edington about XML Data Bindings and how support for XML DOM is implemented with Object Pascal language bindings. Includes MP3 audio and text transcript.
Borland Developer Relations. Mark and John talk about XML Data Bindings,
which provides language bindings for XML Documents and the Document Object Model (DOM).
This support provides code insight and compile-time syntax checking for XML.
Topics include Data Bindings, XML Schemas, and DTDs.
Special thanks to Deborah Pate, TeamB member, for her initial transcription of this interview.
An XML databinding is a way to create a language, a mapping, that ties into your XML data. If you want to think of an analogy, the closest thing that we have today would probably be something like a persistent field that you use on a TQuery or something like that in our existing technology, where by creating this component you're able to reference it specifically in your code. So, the databinding allows us to generate code that you can write using the standard, more or less property-based programming that we're all accustomed to in Delphi. For instance, if you have some customer information that's in an XML document, instead of writing code that traverses down into this XML hierarchy of nodes, and finding the customer's name and replacing it, you simply would write code that would look like what we're used to writing today in Delphi, which is
Customer.Name := 'Mark';
so it makes it a lot simpler. It brings RAD to XML document programming.
Yes, that's correct. In the databindings you'll have a hierarchy of the databindings that mirrors the hierarchy of the XML document itself. For instance, I gave the example of updating customer name. If that customer was part of a purchase order, for instance, then the code might look something like
with PurchaseOrder do Customer.Name.Update
or you could say
So the hierarchy is managed the same way that we manage data structures in Delphi code. There's a one-to-one correspondence between the hierarchy in the document and the hierarchy in the databinding itself.
It gets awkward because, what you can do in one line of code with a databinding might take you eight lines of code if you were doing just straight DOM document programming.
We have a new wizard, which is part of Delphi, that basically takes as input either a standalone XML document (that's actually the data you want to manipulate) or a DTD (or some other type of schema) that you specify as the input. Then you'll be given another screen which will show you more or less the structure, in a treeview, of what the data looks like.
At that point you can decide whether you want to create bindings for everything in the document or just certain things. You can change how types are mapped, whether a particular property is of type string, or integer, and whatnot. More often than not, probably, all the defaults will be fine. At that point you just proceed through to a final page which gives you a review of what's going to be created. Say "Finish," and boom! You have a unit now that's part of your project that you use to manipulate the data.
At that point there'll be a function that you call that gives you a databinding that becomes the root of the document that you do processing with.
Right. That's called early binding, and it allows us to leverage the CodeInsightTM feature of the compiler. If you have something you need to update, and you type something like the example I gave earlier,
at the point you hit the period, you'll get a list with the CodeInsight of all the structures that are valid at that point. You'd see something like
Then you'd press another dot and see
Name, Street, whatever.
The main determining factor in when a databinding is going to be useful is whether or not you know about the structure ahead of time (because you have to have some type of structure in your document), and whether or not it's going to be something that conforms to a DTD (or some other type of schema). When it conforms to a DTD, the databinding actually serves the purpose of enforcing the structure of the DTD. Unless you go outside the scope of the databinding (which is possible through the architecture), if you stick to using the properties and the other structures that are generated, you'll always be conforming to the DTD. It's enforced by the nature of the interfaces that are created.
Probably one of the best examples of a databinding that people will be able to look at in Delphi is the databinding we created for XML Schema, which is the emerging standard for defining structure in XML documents. Over time it will slowly replace DTDs. That databinding is quite complex because XML Schema is quite complex. If you had to go out today and create an XML schema for one of your documents, you'd be hard pressed to do that starting from ground zero because XML Schema is a very complex specification which includes numerous details.
What this databinding does is make it very simple to create a new XML schema, for instance. Say you're going to create a new type. You can do something like
You've now created a type. Then, with a reference to it, you can say
and those correspond to properties that are on the bindings. In that way it's a very natural, simple way of programming your document.
Likewise, if you want to read the data that's in a schema, you can say, "Give me a list of all the elements that are in the schema," which is something the databinding wizard needs to do, so that [you] can know what properties [you] need to generate. There's a simple method that you can call to give you a list of all the elements.
Now, if you had to write code using the DOM, as I mentioned earlier, to go out and get that same information might require 50 or 100 lines of code, and intimate knowledge of XML schema and structure. By using the databinding, you hide all the complexity of XML Schema.
That's kind of a plug for the XML Schema databinding, which really goes beyond what you can do with the wizard. Still, it is a databinding, and it's a good example of what you can do with that kind of technology to simplify the programming tasks that people are faced with.
Well, In that case, you can fall back to the TXMLDocument, which is actually the underpinnings of the XML databindings. Everything is based on TXMLDocument and the primary interface which is used in there, called IXMLNode. In that case, it's a component you drop on the form and point it at an XML document. Set Active to True, and at that point, you can begin iterating over the data.
The hierarchical data will be represented in a childnode list that you can iterate over. If you need, for instance, to display it in a treeview, you would just write a recursive algorithm to copy the data out of the document and into the treeview. You could search through the document using that [method]. It's more like the DOM programming model, and it's not as RAD as the databinding programming model.
Yes, absolutely. One of the things that we've done solves a [common] problem that people have today. As I mentioned, most XML document programming is probably done with DOM today. [People] tie themselves more often than not to a particular vendor's implementation because, although the DOM specification (which comes from the w3c) defines a set of interfaces for manipulating XML data, there are certain parts of it, such as saving a file to disk or loading a file from disk, that aren't part of the specification. Those are left up to individual vendors, who implement a DOM, to decide how to do it.
It's difficult today to write code which will read an XML document that works on Windows and also works on Linux. One of the things we've done to address that problem is, we've taken the interfaces that are actually defined by the w3c, that do the DOM Level 2 specification, and we abstracted out those that are independent of any vendors. They exist in a unit called xmldom.
There's a registration mechanism in place there. For any given vendor (for instance, Microsoft), you can create a unit which maps their implementation into the actual w3c specification. Thereby, it's cross-platform. If you were going to take that same program and bring it over to Linux, you would just simply use a different DOM vendor that's available on that platform.
Transcript produced by White Tiger Communications
These multimedia files are copyright © 2001 by Borland Software Corporation.
All Rights Reserved Worldwide
All Borland brand and product names are trademarks or registered trademarks of Borland Software Corporation, formerly known as Inprise Corporation, in the United States and other countries. Other names mentioned herein may be trademarks of the party using such names. This release contains forward-looking statements. All statements that are not historical are forward-looking. Forward-looking statements may relate to, but are not limited to, Borland's future financial performance, capital expenditures, revenues, acquisitions, earnings, costs, product development plans, global expansion plans, estimated size of potential customer markets, demand for our products, the projected acceptance by existing or potential customers of new technologies and the potential features of, or benefits to be derived from, the products developed, marketed or sold by Borland, market and technological trends in the software industry and various economic and business trends. Such forward-looking statements are only predictions and involve a number of uncertainties and risks that may cause actual events or results to differ materially. Factors that could cause actual events or results to differ materially include, among others, the following: general economic factors and capital market conditions, general industry trends and the potential effects on us of competition in computer software product and services markets, growth rates in the software and professional services markets that we participate in, rapid technological change that can adversely affect the demand for our products, shifts in customer demand, market acceptance of new or enhanced products or services developed, marketed or sold by us, delays in scheduled product availability dates, actions or announcements by our competitors, software errors, reduction in sales to or loss of any significant customers, our ability to successfully integrate acquisitions, any failure by us to protect our intellectual property rights, the dependence of certain of our business units on licenses from third parties, our ability to attract and retain qualified personnel, and other factors described in our latest Annual Report on Form 10-K and our latest Quarterly Report on Form 10-Q filed by Borland Software Corporation with the SEC, copies of which may be obtained from the SEC at www.sec.gov. Borland undertakes no obligation to update any information contained in this release.
Try Delphi XE4 free for 30 days
New Instant Trial!
Webinars on demand!
More social media choices:
Delphi on Google+
@RADTools on Twitter
Server Response from: ETNASC02