Slashdot Log In
No Nonsense XML Web Development with PHP
Posted by
samzenpus
on Wed Mar 15, 2006 12:46 PM
from the serious-development dept.
from the serious-development dept.
Alex Moskalyuk writes "PHP and XML seems like a marriage made in heaven. Powerful manipulation functions and support on the core language level in PHP5 combined with universal extensibility of XML make it a technology of choice for quite a few Web enthusiasts and companies out there. However, anyone inspired by PHP's ease of use can probably find a good cure from insomnia when facing with XML specs. With all the DTD's, XML Schemas, XSLT and XPath queries one can easily get the impression that the world is changing on them, and perhaps sticking to hard-coded HTML with PHP statements combined with SQL statements for data retrieval would be within the zone of comfort." Read the rest of Alex's review.
Thomas Myer's No Nonsense XML Web Development with PHP is an XML primer for those who have been exposed to PHP, but are yet waiting to appreciate the elegance of PHP+XML solutions. Throughout 10 chapters and 2 appendices Myer is introducing the reader to different aspects of XML, their best-practice implementations in LAMP (where last P stands for PHP) environment, and their relevance to the real world. For the real-world example Myer decides to guide the reader through writing a custom content management system - complete with publishing/admin interface, templating/presentation layer, search engine, RSS feeds and other commonly expected features.
The book is not an introduction to PHP, but it does assume that the Web developer knows what XML is, but has never dealt with it. So the first chapter just talks about properly parsing XML with IE and Firefox, validating an XML document, differences between a well-formed and a valid XML document. Overall, it provides a very good introduction to XML for someone who has never dealt with it, and could probably be skipped by developers with XML exposure.
Chapter 2, XML in Practice, goes into nitty-gritty details of XML, and 26 pages later the reader knows how to create an XML file to display in the browser, declare proper namespaces, attach a CSS file to existing XML file and display the proper XML+CSS file (look, Ma, no <html>!) in the browser. The author earns instant geek credibility by displaying Firefox screenshots, with the exception of IE screenshot whenever IE is discussed. At the end of the chapter the author takes us through the basic XSLT.
DTD's, XSLT and writing a practical PHP app take up the next three chapters, followed by XML manipulation chapters. JavaScript enthusiasts will probably find Chapter 6 pretty useful, as it discusses manipulating XML on the client side, working with XSLT, and creating dynamic site navigation based on the XML source. Chapter 7 is what one would expect from the book that has the words PHP and XML in the title - discussion of SAX, DOM and SimpleXML parsers, examples of their implementation, discussion of proper use cases for each one of the technologies. The SimpleXML subchapter also contains a good primer on XPath - a query language that allows the developer to provide the parser with a query to navigate down the XML document.
Chapter 8 takes the reader through RDF and RSS, discusses the ways the syndication feeds are used on the Web nowadays. Since throughout all these chapters we're building a content management system, this is the right time to add the RSS headlines functionality to the site. The next chapter discusses another practical implementation of XML on the Web - XML-RPC calls between the sites and proper ways of exchanging data via XML Web services. The chapter discusses SOAP, although not a whole lot, and just mentions REST as another way to implement Web Services. As a practical exercise, the author takes readers on a tour of building an XML-RPC client, server and connecting those two together.
The last chapter talks about using XML with databases. Native XML databases are discussed, but let's face it - most of the PHP development is done with relational databases anyway. Myer talks about exporting MySQL database contents into XML with phpMyAdmin and mysqldump. The first appendix includes function reference for SAX, DOM and SimpleXML parsing in PHP, while the second one completes the CMS project by providing the rest of the necessary files.
I found the author's style very easy to follow and approachable. The code samples are succinct and to the point, there are also no generic discussions, such as "Why PHP?" The project chosen for the practical implementation is a bit boring, but at the same time quite real-world. The screenshots are clear, and code examples are nicely highlighted. The errata is provided on the book Web site. Code archive is available as a single file download as well. The book site also provides 100% money back guarantee (less shipping and handling fees) to anyone who bought the title, and didn't feel like they were getting their money's worth.
However, there are a few drawbacks that I noticed as well. With topics like XSLT and XPath broken into several chapters and discussed in smaller chunks, it's hard to use the book as a reference later on. Appendix A with PHP function reference for XML parsing hardly seems like a worthy addition, since PHP manual page on the subject contains equivalent information with more real-life examples contributed by users.
With all that, the book is quite informative, educational and useful. The author manages to tackle quite a few difficult topics in 260 pages provided to him (the count excludes preface and appendices). However, kudos to the author for writing chapters on XML without sounding boring, redundant or too academic. I would highly recommend this book to anyone interested in developing PHP-driven Web sites that provide or consume Web services, work with XML data or generate XML for others to use."
You can purchase No Nonsense XML Web Development with PHP from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Better matched, perhaps, than Perl & XSLT (Score:3, Insightful)
Re:Better matched, perhaps, than Perl & XSLT (Score:4, Informative)
Any recent install of java will almost certainly have an xslt processor on it, you just have to remember the magic incantation:
java org.apache.xalan.xslt.Process -XSL [template] -IN [file]Parent
Re:Better matched, perhaps, than Perl & XSLT (Score:3, Informative)
Re:Better matched, perhaps, than Perl & XSLT (Score:2, Informative)
XPath, XQuery and XLST has had really nice implementations since the beginning.
Re:Better matched, perhaps, than Perl & XSLT (Score:2)
Recently in the Ajax world I've started using Googles AXPATH library to handle ajax xml responses at the Javascript client level. Even with old machines and very complex XML, googles xpath javascript library (open source) has worked miracles for recent projects! It's part of googles http://goog-ajaxslt.sourceforge.net/ [sourceforge.net] library - and the xpath piece can be ripped out and used by itself.
Ummm... (Score:2)
Code Download (Score:5, Informative)
Re:Code Download (Score:3, Informative)
$f = fopen('/usr/share/dict/words');
while ($w = readline($f))
{
$c = curl_init();
curl_setopt($c, CURLOPT_URL, 'http://www.sitepoint.com/books/xml1/code.php');
curl_setopt($c, CURLOPT_POST, 1);
curl_setopt($c, CURLOPT_POSTFIELD, array ('word1'=>$w,
'boughtfrom'=>'amazon',
'country'= >'US',
'email'=>'foo@bar.com',
'submit'=>'Downlo ad Code Archive'));
curl_setopt($c, CURLOPT_RETURNTRANSFER, 1);
Can't please everyone, can you? (Score:5, Interesting)
Michael, a web programmer, February 7, 2006,
Almost worthless.
Based on the title, one might presume that Myer and Marini wrote the book for people who are already familiar with PHP and XML and want to learn some advanced techniques for combining them. What he gets instead are long (relative to the book itself), superficial introductions to PHP and XML and tiny, trivial examples of their combination. Everything in the book is common sense to someone who already knows PHP and XML. What the book teaches to beginners, however, is effectively useless for its superficiality, so I'd discourage anyone, especially beginners, from reading this book, even if he receives it for free. Time also is too valuable to waste on this book. Read 'PHP and MySQL Web Development' by Luke Welling and Laura Thompson and 'XML 1.1 Bible' by Elliotte Rusty Harold. One can visit SitePoint's web site to find a list of their titles and then return to a vendor site to read product reviews. SitePoint books are generally sub-par. This book is no exception.
Somewhere, someone at bn.com is shaking their head, wondering if this "reader reviews" thing is all that good a deal after all.
(FWIW: I think the book looks like just what I need, with my n00b level of knowledge of PHP and XML but with hopes to put them together myself [magicnumbers.org], if I can just find the right feed.)
Re:Can't please everyone, can you? (Score:2)
Somehow I always end up going through this process when buying a book online. YMMV.
I guess I was being overly cynical (I'm having that kind of day). One of my criteria for buying a product or service online is that I need to find at least one good result on a Google search for "[product_name] sucks". I learn more by read
XML/XSLT is often more work than it's worth (Score:5, Insightful)
This isn't intended to be me bashing XML/XSLT, but more of a warning. If you plan to use these two, ensure you fully understand them and how they will tie into your site. I've found with OmniNerd that XML/XSLT solutions are very nice for the more static or semi-static content and that using PHP to generate XHTML directly from the database is better suited for dynamic content.
Whatever you choose to use though, good luck!
Re:XML/XSLT is often more work than it's worth (Score:5, Insightful)
XML is good for transferring data between systems. It is not good for storing data, which is what databases are for, or presenting data, which is what applications are for.
Parent
Re:XML/XSLT is often more work than it's worth (Score:4, Insightful)
Well, in the classroom you may be correct, but when you're looking for solutions, XML is often times a better place to store static data than a database. A perfect example is on OmniNerd, when one of our articles gets Slashdotted, or we think it's going to be, we bypass the database and create a static copy of our article in XML. It's faster since no "thought" is required to query specific data as it's all just there. The results have been that our server doesn't flinch when the massive wave of HTTP requests hit our site.
I also use it to store data for parts of the site that remain static. Why insert my FAQ into my database if it's not structured in a dynamic manner? It's far easier for me to go edit an XML file than run a bunch of queries, and we already mentioned the removed burden from the database.
Consider the alternative of storing it in an XHTML file. If I change the style of my site, then I have to update the XHTML file too as it's static. I can quickly translate the XML via XSLT with PHP, ASP, etc. There's no need to touch the data when I make a structural change. So given the static nature not requiring a database, the desire for easy updates, and the need to remove data from structure, I still choose XML.
So, yes, from a purist perspective it's for describing data. But from the perspective of someone trying to run a functional and effective site, it can be useful for storing certain data as well.
Parent
Re:XML/XSLT is often more work than it's worth (Score:5, Insightful)
Parent
Re:XML/XSLT is often more work than it's worth (Score:2)
This all seems pretty smart, and goes along with something that I've been realizing more and more. Dynamic techniques should be used when the content is truly dynamic.
I think that a lot of php + mysql sites are really just using php as a templating system, and that static pages, generated automatically every hour or day or whatever, would serve just as well.
I can say this because I started out doing just that -- mysql/php as a templating system. Now I've moved to Perl + Template Toolkit generated static
An approach used on a site I recently built: (Score:3, Interesting)
The way you've described it, your site still has to run a script for each request. Here's an approach I've used:
Semi-static data (faq, articles, etc) is stored in xml files. Site templates are PHP. Scripts and styles are handled in external files.
There's a directory /view/articles that has HTML versions of the articles; it is writeable by the webserver, but .htaccess rules to reject any requests but *.html . When a change is made to the site layout or newsbar, all the contents of /view/articles are del
Re:An approach used on a site I recently built: (Score:2)
For easier googling, this technique has been called "funky caching" by some people.
Re:An approach used on a site I recently built: (Score:2)
Re:XML/XSLT is often more work than it's worth (Score:2)
Re:XML/XSLT is often more work than it's worth (Score:3, Informative)
XML is designed to be an exchange format.
Databases are designed to hold and maintain data.
Applications are designed to present and modify the data.
My database talks to my application which talks in XML to talk to your application to talk to your database.
XML/XSLT is more work than it is worth because it is forcing the squre block into the round hole with a hammer. XSLT is for converting somebody else's XML into the XML your application wants to consume.
If you have a limited number of users of your r
Re:XML/XSLT is often more work than it's worth (Score:2)
No; XML was designed to be a general extensible markup for textual information. There was no intention to limit its use to data exchange.
XML/XSLT is more work than it is worth because it is forcing the squre block into the round hole with a hammer.
A strange analogy, as XML is general purpose. It is neither <round> or <square> it is anything. Usefully, it is validatable, so if you typed <squre> this could be checked
XSLT is for converting somebo
Re:XML/XSLT is often more work than it's worth (Score:2)
Wrong. XML is a combination of metadata and data. It is an excellent way of storing hierarchical data. If XML is not for storing data, then why is the OpenDocument format XML? Is that not "storing data"?
It's little more than a loosely built, glorified file format. It serves no more purpose to data than tabs seperating "columns" in a text file do.
This is probably why you misund
Re:XML/XSLT is often more work than it's worth (Score:2, Interesting)
That defines data, it does not store it. As I noted in another response to the original poster, XML is not handling any of the storage in any way, the filesystem is handling all of those functions the same way it would if it was retrieving any other type of file. When OOo opens that file, it doesn't use the XML in any way to retrieve the data, it uses the XML as an interface between text-only representation on the disck and formatted sc
Re:XML/XSLT is often more work than it's worth (Score:2)
Well I accept that XML in itself is not a database engine, but it is more that just a transfer medium. It is the format of the plain text data.
XML has nothing to do with storing data. An XML file is not a "storage tool"
You are getting two things very mixed up. Not actually being a storage mechanism does not mean that it has nothing to do with storing data.
Would you say that a Linux Filesystem
Re:XML/XSLT is often more work than it's worth (Score:2, Interesting)
XML's purpose is not data storage, it's data description. People try to use those descriptive properties to generate applications which use XML stored on disk to store data within the stored file, but that's a waste. It's like trying to turn a c
Re:XML/XSLT is often more work than it's worth (Score:2)
Agreed.
People try to use those descriptive properties to generate applications which use XML stored on disk to store data within the stored file, but that's a waste. It's like trying to turn a car into a boat when you could just easily go obtain a boat. Sure, you can do it, but it's inefficient, error prone, and doesn't actually have any pros associated with it in 99.999999999% of all cases.
I still can't quite get your point.
Re:XML/XSLT is often more work than it's worth (Score:4, Insightful)
XML is a key technology, and much underused by my profession, which still relies too much on FrameMaker, Word, and (God help us!) plain old HTML. But it's not the solution to every content management problem.
Parent
A compromise? (Score:5, Insightful)
Some quick advantages:
So even if you don't want to get into XML, XSLT, etc. then using the DOM for page generation is a much better solution than the traditional mixing HTML into PHP into files. The only qualifier to that I can think of is very small sites and when you don't have said libraries and such built up.
When else would hard coding HTML be preferred? I'm drawing a complete blank.
Re:A compromise? (Score:5, Insightful)
The downside to using the DOM as you describe is that you need to generate the whole document before you start sending it. For example, imagine if Slashdot used your approach - on a page with hundreds of comments, you'd have to wait for every last comment to be added to the DOM before you even started to send the headline to the user.
Parent
Re:A compromise? (Score:2)
Re:A compromise? (Score:2)
Present in PHP5 and PEAR for PHP4..but where else? (Score:2)
Re:Present in PHP5 and PEAR for PHP4..but where el (Score:2)
Match made in heaven? (Score:2)
Re:Match made in heaven? (Score:3, Informative)
You don't order nonsense, honey--it just comes (Score:2)
It's getting boring... (Score:2, Insightful)
- PHP saves granny from death
- How to build nuclear reactor using PHP and components from radioshack
- Reliable extraterrestial exploration using php.net functions reference comments
- PHP programmer cured from cancer, aids and herpes (aciquired while trying to understand any basic computer science topic)...
- PHP Saves! Better than Jesus!
- PHP - a quick guide to shopping.
C'mon nerds - trying to manipulate XML with common PHP functions is like trying to hang a p
XML data and HTML middleware (Score:3, Interesting)
A lot of the middleware that converts data to HTML and back can go away when you use the right XML tools. XSLT does a good job of presenting static pages, and it can be fast if you cache the results as well.
But for dynamic pages (and forms) XML to XSLT to HTML leaves some big gaps:
These are some of the reasons we updated the W3C HTML forms module [w3.org] to take account of XML data directly.
How does it fix the above problems?
Nice work if you can get it, you say? Well, as everyone knows Microsoft hasn't yet implemented XForms. (Heck, they haven't even implemented CSS, though we hear they do have it as a goal now.)
So what can you do today:
Here's a quick example:
Let's suppose you have a book list you want to view, avaialble at http://example.com/books/list [example.com].
If you want to display this data
Match made in heaven (Score:3, Funny)
Is that another way of saying that they deserve each other? *ducks*
Joy and Sorrow (Score:5, Insightful)
PHP is losely typed, full of hacks (excellent hacks that make coding easier) and is great exactly because it allows the coder to be pretty careless and have the language look out for him as far as possible.
XML, on the other hand, is strict and harsh on the coder. Forgot to close a tag? Wrong character somewhere? Not got the tag order correct? Sorry, your entire tree fails parsing.
They just don't mix well, and it shows everywhere. I'm currently coding a PHP app using XML-RPC, and gosh is it convoluted. You've gotta cast practically everything into the special XML-RPC values and back out again. You'd expect the libraries to have functions doing that for you, but you'd be mistaken. On the average line stuffing together an XML-RPC call, the whole "new XML_RPC_VALUE" stuff takes up twice the space of the actual variables.
Doesn't mix well. Sorry, I like PHP a lot and XML is an excellent thing. But they just don't mix well.
Re:wut (Score:3, Insightful)
XML stands for Xtremely Media-hyped Language and PHP stands for Perl-Hater's Platform. They are both very overused and should be ignored from this point on. Oh crap. I guess I get a free downmod for going against Slashdot culture. Oh well.
No, you should get the downmod for posting a moronic comment that contains flamebait only with no facts or even anecdotes to back it up. You rightly deserve at least a -3 for such a comment.
Re:wut (Score:2)
At least a -3? +5 is greater than -3, right?
:)
I suppose I was speaking negatively rather than mathematically
Malice (Score:5, Funny)
Dude, calm down! Hating Perl is not something developers do out of malice. It's a bit more like the obvious conclusion a child draws about fire after getting burned for the first time. Of course there are also some people, like you for example, who enjoy pain....
Parent
Re:wut (Score:3, Insightful)
That said, as any Lisp programmer will tell you, tree-structured data is a Good Thing(TM). There's a reason why reading in input like:
is complicated and fragile, whereas reading in input like:
is so trivial that, well, I just typed this into
Re:wut (Score:4, Informative)
I think the parenthetical version and the XML version are about equal in terms of readability once you remember that any decent editor will have syntax highlighting to emphasise the text over the tags and that both versions will typically be split over multiple lines. Linebreaks don't really aid readability when you have short ending delimiters, but they do when you have longer ending delimiters.
The idea that XML is just a reinvention of s-expressions is quite popular, but this article [prescod.net] does a decent job of explaining how they differ.
Parent
Re:wut (Score:2)
It's also imperative, which makes it a lot easier for many people to use than a functional language like Scheme.
Re:wut (Score:2, Informative)
That's a common misconception of what XML is. XML typically refers to XML and related technologies
It's not just key/value pairs. (Score:4, Informative)
In an XML file, I can throw in extra attributes or elements that won't be read by an old version of an app that wasn't looking for them. In a simple comma-separated-values layout, if I add something to the format, it's completely incompatible with previous versions.
The most complicated tools you have for comma-separated values are along the lines of cut and sed. When you have an XML document, you can convert it to *any* other XML format with a simple XSLT stylesheet (or, for that matter, into non-XML formats). SQL-Select-like statements can be represented with XPath, letting you select various fields of nodes which contain a certain attribute, act on the a certain way, etc.
Any anyway, would you look at an HTML document and say "it's just key-value pairs"? No! The order of elements, the hierarchy of data, etc, all makes up the page as a whole. HTML was an application of SGML, which XML was derived from.. Use XHTML if that last bit confuses you - it's not key/value pairs.
People have thrown the buzzwords at you because they're either really impressed with the technology, or because they're the kind of people that like buzzwords. Ignore the latter group of people, and try to focus on why those of us in the first group are singing its praises.
Parent
Re:It's not just key/value pairs. (Score:2)
Somehow, I feel the word simple is inappropriate here. XSLT style sheets are hairy beasts, powerful, but tough to master.
Re:wut (Score:4, Informative)
And BTW, XML is a tree format, not strictly key/value. And when you parse an XML file, you're never having to do direct text manipulation (which is error-prone). You're either receiving the information stored in the XML file as a series of events (SAX) or you're manipulating it via an object model (DOM).
Parent