Forgot your password?
typodupeerror

No Nonsense XML Web Development with PHP 131

Posted by samzenpus
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.
No Nonsense XML Web Development with PHP
author Thomas Myer
pages 354
publisher SitePoint
rating 9/10
reviewer Alex Moskalyuk
ISBN 097524020X
summary XML, XSLT, XPath and DOM primer for PHP developers


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.

No Nonsense XML Web Development with PHP

Comments Filter:
  • by Orrin Bloquy (898571) on Wednesday March 15, 2006 @01:54PM (#14925659) Journal
    One thing I will concede to PHP is that you tend to be more likely to have XSLT engines installed on a PHP based system, whereas I had to cajole my sysadmin into getting the C-based transformation libraries installed and then locally install the dependent Perl libraries to use it on top of that. In the end the Perl/XSLT solution I created works, but it wasn't fun to install.
  • Code Download (Score:5, Informative)

    by saberworks (267163) on Wednesday March 15, 2006 @01:56PM (#14925679) Homepage
    I tried to download the code examples but the site is asking me for a special code that is printed inside the book. Bleh.
    • Re:Code Download (Score:3, Informative)

      by twitchkat (566638)
      <?php

      $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);
    • It asked me for my email address (the same I used when I ordered the book not fine minutes ago).
      On a totally unrelated note, I wonder if the e-mail address I have in my profile still works though I have nooo idea what I could send in return to the kind spirit who would help me test it...
  • by RobertB-DC (622190) * on Wednesday March 15, 2006 @02:00PM (#14925702) Homepage Journal
    From the bn.com reviews, a contrarian view:

    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.)
    • "Somewhere, someone at bn.com is shaking their head, wondering if this "reader reviews" thing is all that good a deal after all."

      OTOH, but maybe the glass is half full. Personally, based on his positive mention, I'd then copy-and-paste the 'PHP and MySQL Web Development' and 'XML 1.1 Bible' books into the BN search.

      Somehow I always end up going through this process when buying a book online. YMMV.
      • OTOH, but maybe the glass is half full. Personally, based on his positive mention, I'd then copy-and-paste the 'PHP and MySQL Web Development' and 'XML 1.1 Bible' books into the BN search.

        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
        • 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".

          Y'know, that's one of those things that sounds obvious but really isn't. Maybe human nature is to look for the positives first since that seems the most natural path toward finding the best product quickly.

          Probably also explains the success of Ebay (of which my cynicism and intense fear of being suckered prevents me from buying anything there).
    • I think this book is a great idea, but I'll never buy it. I currently use PHP to generate HTML, and I'd like to move to XML, so it's the perfect topic for me. But books go out of date fast, and there's too many free resources on the web that are constantly being updated.

      So, does anyone know of any good links for learning about the use of PHP with XML? I know I could google for some (and I have), I was just wondering if anyone has something that they would recommend.
    • Somewhere, someone at bn.com is shaking their head, wondering if this "reader reviews" thing is all that good a deal after all.

      What? A review says "don't buy this one book; buy these other two instead."

      Sounds like exactly what a bookstore would want.

  • by markmcb (855750) on Wednesday March 15, 2006 @02:01PM (#14925719) Homepage
    I authored the site OmniNerd [omninerd.com]. When I first started writing code, I made a point of storing data either in a database or XML, translating data to XHTML with XSLT, using CSS for all style issues, and controlling everything with PHP. What I struggled with for over a year was the XML/XSLT portion of the site. I was constantly having to jump through all sorts of hoops to get things done that could easily be handled with just PHP and a database.

    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!
    • by G)-(ostly (960826) on Wednesday March 15, 2006 @02:13PM (#14925844) Journal
      XML is not for "storing data". I can't believe people still find that confusing in this day and age. XML is for describing 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.

      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.
      • by markmcb (855750) on Wednesday March 15, 2006 @02:29PM (#14925980) Homepage
        XML is not for "storing data".

        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.
        • by G)-(ostly (960826) on Wednesday March 15, 2006 @02:48PM (#14926161) Journal
          You're not storing the data "in XML", you're storing it on the filesystem in files that describe the data via XML. The performance benefit of the static data over the RDBMS data store is provided by the filesystem, not as a function of XML. To the contrary, your retrieval of the data is actually hindered by the XML because it increases the size of the files that must be retreived and transferred.
          • gzip encoding is a Good Thing and should be used wherever possible on compressible data. XML is no exception and can benefit greatly, (unless the data it contains is uncompressible and large in comprison to the XML skeleton).

            For high volume traffic and SSL, then processing can be offloaded to an instream device such as jetnexus and let the web server do what it is best at.
        • 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

          • A dynamic, templating system should be used where the updates to the site are so frequent that it would be unreasonable to expect that the site's maintainers would be able to keep up if they had to edit the pages every time the state of the system changed. Slashdot would be a prime example.

            However, if you are not changing data frequently, or the state of your site is not necessarily subject to the input of its users, you don't really need a database system at all, unless you're merely tapping it because it
        • 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

        • One approach used on a site I helped develop (although admittedly under Java, it would would work for PHP just as effectively), was to store the data for the pages in xml files which were easily edited, validated using a desktop editor such as Oxygen. Once the data was updated and uploaded to the correct location, we had an admin interface which allowed the administrator to republish the entire website as static pages. I have done the same thing from a database in the past of course, but using XML allowed u
        • Probably, but while people are still in love with it we should get a stream of good data handling tools. Thanks for being the guy who said the emperor has no clothes.
      • Agreed.
        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
        • XML is designed to be an exchange format.

          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
        • XSLT is for converting somebody else's XML into the XML your application wants to consume.

          Like _your_ XML into XHTML (a XML format) that your visitor's browser (and application) wants to consume?

          Client side XLST would make this alot nicer.
      • XML is not for "storing data". I can't believe people still find that confusing in this day and age. XML is for describing data.

        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
        • If XML is not for storing data, then why is the OpenDocument format XML?

          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
          • In other words, it's a transfer medium to translate the plain-text data to an actual office document, nothing more.

            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
            • No, XML should not be used in relation to storing data. You can build a system which uses XML to store data, I'm not contesting that, and I already mentioned what that technology is: it's called a heirarchicial DBMS, and they've long been known to be inferior tools.

              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
              • it's called a heirarchicial DBMS, and they've long been known to be inferior tools.

                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.
                • When talking about "storage", we're talking about certain properties and functions that relate to actually manipulating, storing, and retrieving the data. For example, a filesystem is involved in "storage" because it provides functionality for all of those things, whether moving the data into a more logical structure (manipulation), or saving (storing) or fetching (retrieving) it.

                  XML doesn't intrinsically do any of these things. When people speak about "storage" in XML, they're talking about applications th
                  • I can begin to see where you are coming from. However, I still don't quite agree. Storage is about more than just live databases. It can be about repositories and archives. This can be an area where XML is very important, as it has been specifically designed as a format that is resistant to becoming unreadable over time, perhaps due to the software that writes a format becoming unsupported. Doing long-term archives as, say, Oracle export dumps just isn't good enough!

                    On the matter of XML being error pr
                    • This can be an area where XML is very important, as it has been specifically designed as a format that is resistant to becoming unreadable over time, perhaps due to the software that writes a format becoming unsupported.

                      ?

                      Yes, but it's not actually a storage system, so it still has to be stored in one, so it's still going to be subject to the problems you mention.

                      If you want to avoid such problems, you can prevent them.

                      But you have to define that on a case-by-case basis, it's not an inherent enforcement like
                    • Yes, but it's not actually a storage system, so it still has to be stored in one, so it's still going to be subject to the problems you mention.

                      No, it is not addressing the issues of storage systems going out of date, it is addressing the issues of data formats going out of date.

                      But you have to define that on a case-by-case basis, it's not an inherent enforcement like one finds in relational systems.

                      There are few inherent enforcements in relational systems - things constraints and foreign keys are optional
                    • ...it is addressing the issues of data formats going out of date.

                      But data formats aren't storage, they're representation.

                      There are few inherent enforcements in relational systems - things constraints and foreign keys are optional
                      There are many inherent enforcement in relational systems. There also happen to be many psuedo-relational system masquerading as something they're not.

                      Also, you can't impose in a relational system the range of constraints you can impose with XML, such as ordering of data.

                      That's not
                    • But data formats aren't storage, they're representation.

                      But then relational database files aren't storage - they are representation. If you want to proceed down that path, storage is nothing but magnetic domains on disk.

                      There are many inherent enforcement in relational systems. There also happen to be many psuedo-relational system masquerading as something they're not.

                      Very true.

                      That's not true, you can order your datasets in any way you want when you retrieve them as long as you put them in in a meaningful
                    • First of all, it's misleading to say that RDMBSs work in terms of "sets". They work in terms of relations, and a relation can be as restricted as a single attribute and tuple pairing, or as complex as the entire set of data.

                      Fair enough.

                      Secondly, RDBMSs have no sense of "order" becuase they don't need it.

                      Well, RDBMSes don't need it, because they store data that doesn't need it. Not all data fits neatly into relational form.

                      Third, XML imposes no constraints.

                      Not of itself, but it has the ability to.

                      Relationa
                    • Please provide an example of data that can't be cleanly set into the relational model.

                      Irregular data, such as a polymorphic list of objects of different types. Especially data that is frequently changing (say, new subclasses of objects are added).

                      Huge data stores in archaic, convoluted formats are difficult to manage when they're in transition, yes, but I really don't buy the argument that XML is a universal solution to the problem. Even if you use XML, you still have to have both ends of the transaction a
                  • "For example, you may have an application that performs a website search by looking through XML files for a list of names. It will open the file, find the tags, and then test the stored data against the criteria, contining until it finds what it needs. This is a waste, as the task could be performed much better by a RDBMS."

                    Would you please explain where the data in your example is "stored" if not in the XML file that you just plainly stated is being searched by the web application. It does not matter one w
                    • Would you please explain where the data in your example is "stored" if not in the XML file that you just plainly stated is being searched by the web application. It does not matter one wit what is better, RDBs or XML. RDBs "store" there data in files on a file system.

                      I have explicitly stated that I am not denying that people create storage systems based on XML, I have explicitly given the common name to those types of storage systems twice. Please be sure to read the entire thread through before responding
                    • If what you are saying is that the meta-data in, say, a PostgreSQL table file, sans data, is not storage, then I agree with you. The problem is that that data alone is meaningless except to clone structure. Once you ad some data, the file is then /storing/ that data. This is true for any file. the XML spec, like the Postgres table spec is all about how to store data.

                      "I have explicitly stated that I am not denying that people create storage systems based on XML"

                      You have stated that XML files are not stor
      • i dare say that you just don't understand all practical uses for xml. i'm currently working on a front end for a hardware configuration file... let's see, i'm probably storing up to a maximum of 100 pieces of information. would you recommend oracle to store that data? okay, how about postgresql (my fav, anyway)? i'd argue, xml is perfect to *store* and describe this information, which is why we chose to use it. postgresql would just be flat out overkill.
    • by fm6 (162816) on Wednesday March 15, 2006 @02:17PM (#14925880) Homepage Journal
      That's a very good analysis. I'm a strong XML/XSLT advocate, but only because I work with the kind of documents that need them: big nasty technical manuals and guides that have a lot of complicated structure, are always be updated, and have to be delivered in multiple formats. When someone challenges by XML dogma, they always point to some project they've worked on that would have been much harder if they'd had to use XML. Most of the time (not always!) they're right, usually because the particular project is a one-shot document that will see little or no revision. Of course, that just says that XML is useless to them.

      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.

    • I would say using XML/XSLT was a good solution where you need multiple output formats, while using PHP to generate XHTML from the database would be best suited when XHTML is all you need. There is nothing to stop you using PHP to generate XML from the database then apply an XSLT to it if you need both dynamic data and multiple formats.
    • True.

      I re-worked my personal website to use XML for all the page data and XSLT to render the pages into HTML. I have both static and dynamic pages. I tried to keep all formatting out of my XML files with the exceptions of things like "bold", "underline", etc.... PHP scripts generate XML which is rendered to HTML in the same way.... I was thinking that eventually, I could add the ability to export the current page as a PDF, etc...

      Well, it didn't quite turn out as well as I hoped. I had to re-implement
  • A compromise? (Score:5, Insightful)

    by MasterC (70492) <cmlburnett@gm[ ].com ['ail' in gap]> on Wednesday March 15, 2006 @02:11PM (#14925819) Homepage
    Since I started using PHP's DOM functions, I haven't written a lick of hard coded HTML except for templates that I import into DOM. I create template tags within the template as hook points so on loading the template into DOM I can cache a list of all these template hooks (and remove them so the template is back to valid HTML) and then I can inject my dynamic content directly into where the hooks are.

    Some quick advantages:
    • You don't have to worry about closing your tags, just assigning parents
    • You can modify your tree at any point in execution (such as style changes, removing sections of the page based on user input, etc.)
    • Outputting HTML or XHTML doesn't change your DOM tree
    • You can more easily write code with more separation between functionality (model) and interface (view)
    • If an error occurs then you don't have to worry about the "headers already sent" issue
    • You can easily create DOM manipulation libraries to do a lot of the tedious tasks for you (element creation, attribute population, etc.)

    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)

      by Bogtha (906264) on Wednesday March 15, 2006 @02:22PM (#14925915)

      When else would hard coding HTML be preferred?

      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.

    • What you've written intrigues me. I've never heard of this before, and now I must do some research! Anybody else have experience with this method and wish to share?
      • Uh, kinda. I wrote a set of DOM classes in PHP about four-five years back. They were handy at the time, because my goofball team leader decided midway through the project to process all the HTML as XHTML, but didn't bother to actually tell us this. So then we had to go through all our stuff and rewrite it to be conforming. The DOM classes worked, but they were more cumbersome to use, and took more time to generate the page. I haven't used the PHP5 DOM classes, presumably they're (much) better than the
    • Re:A compromise? (Score:1, Insightful)

      by Anonymous Coward
      You can modify your tree at any point in execution (such as style changes, removing sections of the page based on user input, etc.)

      This is not good from a programming point of view, OK the presentation and business logic are kind of seperated, but you seem to be encouraging the business logic to modify the template... This is very bad design.

      What if you need to output a non-XML format like CSV or PDF? XSLT is dead slow and shouldnt be used for live transformation (IMHO)
    • What's "hard" about HTML? Can't expect to be able to exchange a DOM with a page designer. Assimilating the HTML into script code, programmer becomes a rate limiter, a bottleneck. XML/XSLT won't work for the same reason. On the contrary, maintenance programmers ask that we please use page templaters such as smarty, freemarker, the one's built into Django and RoR.
  • by Anonymous Coward
    Perl is developed by a good Christian man whom would never engage in sexual relations with another man. Perl should always be chosen over PHP.

    Praise Jesus!
  • The book uses PHP5's built-in support for XML. PHP4 can have similar support through PEAR. But what should those of us who release PHP apps targetted for use by people who might still be on PHP4 hosts with no PEAR use? I've used the ActiveLink PHP XML package [active-link.com] with good results for creating XML, but it doesn't yet have any support for XSLT and XPath. Are there any minimal packages which can supply this without having to rely on PEAR or PHP5?
    • One nice thing about PEAR is that it's just a collection of .php files. My handrolled CMS has a few unusual PEAR requirements so I never bother trying to use a shared hosting setup's PEAR environment. I just create a directory in the documentroot and upload the /pear/PEAR directory from my box at home. Set the include path (via php.ini, .htaccess, or least preferably in .php file itself) and all the PEAR includes work...
    • PHP4 has DOM/expat/XSLT support. i suppose its not as comfy as PHP5, but i massage XML all the time and the tools available in 4 do the job.
  • When PHP has robust Unicode support ... maybe.
    • You want mbstring [php.net] which supports, among other things, the UTF-8 incarnation of the Unicode standard.
    • Unicode is of no use to those of us in these great United States! Everyone here speaks English, except those who don't, and to hell with them (literally - they're going to hell for being foreigners)! If you use Unicode, or even want to, the terrorists have won!

      God bless America
  • The title of this book is disingenuous! XML and PHP each come with a huge helping of nonsense that you can't get rid of. Together, they're... *shudder*
  • by KZigurs (638781)
    Reccomended headlines for next PHP fanboys posts:
    - 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
  • by leighklotz (192300) on Wednesday March 15, 2006 @03:49PM (#14926703) Homepage

    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:

    1. The hierarchical XML data gets flattened out into name/value pairs in HTML form fields.
    2. For the return trip HTML->?->XML, XSLT doesn't work; you can't run the transform backwards.
    3. For dynamic pages, you're left with JavaScript or the dreaded "postback."

    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?

    1. The hierarchical XML data your PHP or other server-side code outputs is transmitted directly to the web browser, where it remains while the user futzes with only the nodes that the form specifies. The middleware that converts the XML data to web browser data is just printing the XML.
    2. When the form results are submitted, they come back directly in XML, so there's no need to pick apart the name=value pairs and try to put them back into your data. The browser just posts the XML directly back as XML to your PHP or servlet.
    3. For forms, as the data changes, the UI changes with it. If a node disappears, or appears, or if a value changes, entire sections of UI can appear and disapear just by listing a dependency on that data. And if you want dynamic pages, you can use the background submission feature to retrieve instance data asynchronously, and the presentation changes automatically.

    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:

    1. Use Mozilla or FireFox XForms 0.4 [mozilla.org]. It's a one-click install download from the Mozilla website. Yes, it's beta. Yes it has bugs. Yes, IBM and others are fixing them. But it's open source.
    2. Use FormFaces for most modern browsers (Firefox, IE, Safari, Opera) FormFaces [formfaces.com] is a cool JavaScript/AJAX application that you import into your web page with a one-line include, and it does everything described above. If you need cross-browser support right now, want dynamic AJAX forms, and want to interface to XML, this is your best bet, if you can tolerate a JavaScript program in your browser (i.e., it's done using AJAX). It's available under GPL and commercial licenses.
    3. Use Chiba for backend processing Chiba [sourceforge.net] is an open source Java-based back-end that converts your XHTML+XForms page into either an AJAX page or a static HTML page (good for Sec 503 compliance). Chiba is a great choice for applications that have a Java back end, as it puts less load on the browser than the large JavaScript engine of FormFaces, but I put it below FormFaces here because of the emphasis on PHP. (But, about half of Chiba is an XSLT transformation so a PHP port is possible.)
    4. Use Formsplayer as an IE plugin FormsPlayer [formsplayer.com] is a deluxe XForms processor plug-in for intranet applications using Internet Explorer, and has lots of other features as well, such as sidebar support.

    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].

    <books>
    <book>
    <title>No Nonsense XML Web Development with PHP</title>
    <author>Thomas Myer</author>
    <book>
    ...
    <books>

    If you want to display this data

  • The book is 99% simpleXML, a useless bloated library extension of php5, tutorial. there is mention of sax and dom but very very brief, you can easily find better references at php.net and they are the real world tools for php/xml.

    I was disappointed to find that the author barely used php5 dom functions to support the CMS (if you can call it that) that you are being tutored along because that is definitely one of php5's strong points. i was looking for a book with function references and some code examples
  • by dracvl (541254) on Wednesday March 15, 2006 @05:57PM (#14927964) Homepage
    "PHP and XML seems like a marriage made in heaven."

    Is that another way of saying that they deserve each other? *ducks*

  • Joy and Sorrow (Score:5, Insightful)

    by Tom (822) on Wednesday March 15, 2006 @07:27PM (#14928740) Homepage Journal
    I can't imagine two languages less suited for mixing than PHP and XML.

    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.
    • Seems more like a problem of your XMLRPC lib. Except date everything can be written in native PHP types and the lib should use that information to construct the request or response. One example can be found in the XMLRPC client in the new Zend Framework. I've done it myself and it's really not that hard.

      One example of PHP and XML working together quite well is the Flux CMS made by Bitflux (chregu from Bitflux worked on the new XML libs in PHP5).
  • please visit here...

    http://www.sitepoint.com/forums/showthread.php?t=3 54632 [sitepoint.com]

    if you know some cool php5 / DOM / XML / XPath / XQuery / XSLT scripts, be sure to visit and share for all the newbs.

    i have set up a few example scripts to get you started. others are more knowledgeable than i and can answer more specific question, too.

    i've found learning the DOM to be a royal pita. php4 is very very different than php5. different versions of php5 behave very differently. my recommendation - get the latest and g
  • This is the most dissapointing PHP book I've read. The 'sample application' built during the course of the book is a complete P.O.S and has so little respect for the concept of instilling best practices early on that beginners are the LAST people I would be recommending this book to.

    Ok, so it's no good for beginner and too basic for anyone else...

    One positive note though -- the introduction to designing and using DTDs is quite good, especially for newbies, but that alone is not worth the price of the book.

    P
  • Here [raquedan.com]

    It's brief but I hope it helps. It's a good book by the way.

"Just think of a computer as hardware you can program." -- Nigel de la Tierre

Working...