Forum Moderators: open
I've been very curious about XML for quite a while and while I've read some background information on it, I'm not quite "getting it" in regards how it can be use to make web development better/more efficient/etc/etc.
My projects are all PHP/database driven. All of my projects also use a framework methodology that I've written. So far, so good. But how can XML help me in my daily workflow efforts? Can someone give me a few examples of what XML has done to make their web development lives easier and/or more efficient and/or easier to maintain?
Other than formatting RSS feeds, I REALLY don't know what it can be used for in the real world.
Appreciate everyone's input!
Neophyte
If you are comfortable using php, or asp for that matter, or any other form of db, and it works for you, I say stick with it. XML is easy to edit and style with XSL and CSS, but it is not perfect for all db driven sites. I use it to display listings on a directory site and it works great for that. I use it on another site which is e-commerce, and it works well for that too. I think it biggest disadvantage over a normal db is search ability, but that is my opinion.
Marshall
Thank you for your input; so, in "some/many/most" real-world applications, XML is used to replace a db? Or it's used to format db output?
I am by no means a php expert and use asp to parse my xml files and xsl to format the output and css for styles in the HTML markup.
Did you check the W3 School tutorial [w3schools.com] on XML?
Marshall
Thanks for the W3Schools link. Will take a look and see if that clears the fogs.
Appreciate the input!
Neophyte
When we display our class schedule, rather that querying the database for every user request - we access an XML version of the data that has been placed on the web server. The XML is automatically updated whenever we make a change to the schedule. This greatly reduces the load on the database server and allows the website to function even if the database server is down.
Marshall
I have a site with a large database of events that occur regularly. Each of these events has address information, special agenda information, time, date, etc.
I developed a special XML export of this DB. It isn't RSS; it's custom XML, described by a schema.
The site is one belonging to a central organization.
I have written another site, expressed in WordPress. I have plugins written that execute XSLT scripts on the XML in order to produce a "pinned map," using Google Maps API [google.com]. In order to do this, I have an XSLT script that transforms the XML feed to JSON objects.
I also directly transform the XML to XHTML in order to produce a list of events, and to provide single event detailed listing.
Last, but not least, I have an XSLT script that transforms the XML into WML 1 and WML 2 for mobile phones.
I don't use XML to store the data. I use it to transmit the data across servers. The central server is unable to run XSLT, but you don't need anything fancy to create XML. The WordPress server can run XSLT.
A script creates the XML periodically from the db. The website only sees the XML.
1) configuration settings. When I build a multi-purpose application, I'll keep application config settings in XML so they can be changed easily when it's installed on another site.
2) REST web services. I'll turn frequently-used scripts into a web service, especially if they are going to be offered as an API to the public. A good API doubles as a DAL (data access layer) even within the same application. if the service is going to be used in AJAX applications, I'll make the same service also available in JSON.
3) caching complex SQL jobs. I'll sometimes store really heavy calculations in an XML format so I don't overtax the SQL database with repeated queries.
4) SQL output as native XML. Occasionally I'll build a stored procedure that outputs XML instead of a record set. Some databases do this very efficiently. I'd do this most often if the data is going to be offered as an API, or if the result will be rendered on the page without further ado.
5) internal application objects. It's sometimes easier to buid a complex data object as XML, especially when it's going to be rendered on the page soon after. Forego the loops and ifs and prints, and do it with an XSLT transformation instead.
6) separation of application and presentation layers. When the engine just outputs XML, I can build multiple skins for an application with XSLT and CSS. I contribute to one large project done this way: all page requests start with an engine that receives a request and outputs pure XML. Depending on the skin chosen, it introduces the XML to a discreet collection of XSLT, JS, CSS, JPG/PNG/GIF files which comprise the "skin". output to the user is all valid XHTML.
7) hierarchical data. Hierarchical data like a sitemap or a category tree is a no-brainer for XML.
8) user-entered data. Rarely, but worth mentioning. If you're accepting complex data sets from an uploaded file, XML is a good format to accept. I prefer XML instead of CSV because it can be validated with a Schema and/or DTD.
9) importing data into Flash. Flash has a pretty decent XML parser built-in. it's been capable of Asynchronous Actionscript And XML (AAAX?) since version MX. Great for displaying those high score lists!
Also, I store formatted documents in my database using XML format, along with other bits and pieces such as sitemaps, templates and widgets.
I build all my web interfaces as a DOM Document these days so, XML is the defacto native format on my web app framework. With this approach you can consider DOM nodes to be like bits of Leggo which clip together to form a finished webpage/document. Which, is a lot more powerful than the old school, series of concantenated strings approach.
