Slashdot Mirror
No Nonsense XML Web Development with PHP
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.
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.
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.
"Made up/misattributed quote that makes me look smart. I am on
I tried to download the code examples but the site is asking me for a special code that is printed inside the book. Bleh.
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, if I can just find the right feed.)
Stressed? Me? Of course not. Stress is what a rubber band feels before it breaks, silly.
I authored the site OmniNerd. 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!
Mark A. McBride -- OmniNerd.com
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.
It's not enough to bash in heads, you've got to bash in minds. - Captain Hammer
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.
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....
Only to idiots, are orders laws.
-- Henning von Tresckow
I agree. XML is no more than a text file with key/value pairs in some form of organization.
I'm not saying XML isn't useful I'm saying it's not that impressive as a "technology". It falls under say the Dewey Decimal system in terms of excessive usefulness to society.
PHP on the other hand ain't bad. It's a bit simpler than Perl and IMHO meant to be a bit more lightweight. In the grand theme of things there is no reason why you could SSI perl script [hint: I did it with a CGI script that would parse my own special brew of perl/html].
Tom
Someday, I'll have a real sig.
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.
:wq
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!
...this topic should be from the 'Oxymoron' department.
MY GOD>>>
I so want to rectally explore you now more than ever!!!
PLZ SECKS?
At least a -3? +5 is greater than -3, right?
That's a common misconception of what XML is. XML typically refers to XML and related technologies
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 DrScheme:and copy-pasted the second one into the input box, and DrScheme understood it perfectly.
Regexps are basically a hack to deal with data, like the first log file (which is what it actually looks like on my system), where the structure has been compressed/eliminated. In a perfect world, everything would be tree-structured, and none of those hacks would be necessary.
But wait... that's XML!It's harder to read than the parenthetical version, and slightly harder to parse (especially if there are attributes inside the XML tags), but the two are basically equivalent.
In Scheme, at least, you can build a generic XML-to-s-expression parser that will allow you to deal with any XML data that comes at you as easily as if it were parenthetical. And by generic, I mean that it can deal with any (well-formed) XML data ever. By contrast, regexps are fragile by definition. Even splitting along whitespace isn't always safe.
As far as PHP goes, I couldn't care less... it's both slower and less flexible than Scheme. What a combo! (Of course, Perl is too...
It was probably the same library. libSablot is used by most of the languages that support XSLT on Linux/BSD.
Wow a savings of $15 if you buy it at Amazon! How the hell can B&N compete?
It's still just key/value pairs. What they MEAN is a totally different thing.
It's overly generic and the problem people like me and the OP have with it is that PHBs pick up on it and mandate the next project must have XML support even if they're not a web server or such.
Just like how many people have blackberries that don't need them or any of the other hip bullshit out there. It's just catchy to say "XML this" XML that in conversation. If you meant XHTML say fucking XHTML.
I don't call object files "C programming files" just because a compiler can turn C into object files. Why call XHTML "xml" because you use te XML syntax to produce it?
Put it this way, [for instance], databases have been doing quite well for the last 20 to 30 years. Now they all simply MUST have XML technology in them. Can you honestly tell me XML support makes Databases more efficient?
Tom
Someday, I'll have a real sig.
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 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?
The beauty of XML is that the format is simple and there is a huge stack of technologies that build on it. If you store some data in an XML format, you instantly have the ability to transform you data into any number of formats (via arbitrarily-complex XSL transforms), perform automatic validation (via XML schema or a DTD), perform arbitrarily-complex queries on your data (via XPath/XQuery), automatically include other resources (XInclude), etc. Thanks to namespace support, you can aggregate multiple XML data formats into a single document -- an example of which is XHTML, which allows a single web page to include things like mathematical annotations (MathML), vector graphics (SVG), multimedia (SMIL), complicated input forms (XForms), and so on. Like so many other people, you just see XML as a substitute for comma separated value files, and don't realize the rich set of complicated functionality that's available to you "for free" just by storing your data in an XML format.
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).
At least a -3? +5 is greater than -3, right?
:)
I suppose I was speaking negatively rather than mathematically
It's not enough to bash in heads, you've got to bash in minds. - Captain Hammer
uhh, you can include the PEAR modules within the codebase of your application, so PHP4 users don't have to already have pear installed on their server.
the only permanence in existence, is the impermanence of existence.
When PHP has robust Unicode support ... maybe.
If you just want a (x)html template engine, use clearsilver. XSLT is for transforming some else's XML you don't like into your XML you do like. Its awkward and painful for html templating.
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 does a decent job of explaining how they differ.
Bogtha Bogtha Bogtha
XML as a technology isn't that big of a deal, but then look at what it aims to do-- send simple data.
However, XML as a standard is incredibly important. It's got crazy extensibility, due mostly to its simplicity. It's incredibly fast to learn and human readable. Most most important, lots of different people with different setups using different protocols can send data back and forth. Were there equally-qualified technologies to do this before XML? Of course. Did nearly everyone in the world use them?
Well, now after throwing all that out there, I reread your post and realized this is exactly what you said. So kindly disregard any contrary tone this post might have had and replace with an agreeing tone.
No, it's not just key/value pairs. It's hierarchical. The hierarchy itself contains data - where things are located. You can't express rich hierachical data easily in a flat key/value layout.
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.
..Jeff Keegan
seven syllables explain TiVo: kee gan dot org slash ti vo
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 deleted. If a change is made to just one article, only that article's html is deleted.
On 404, the errorDocument is a php script which:
Thus the XML/XSLT stuff only happens when changes are made and apache can just send the file
I'm working on adding customer-specfic elements to each page. This is via Javascript+Cookies+AJAX so it doesn't need each page to be regenerated for each user. The few pages that are customer-specific but have few static parts are just plain-old PHP that includes the site template file.
Sorry... I commented and reversed my earlier moderation.
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...
http://metapundit.net
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*
Thanks. I suppose I should have elaborated that I wanted something that was (if possible) (1)lighter weight and (2)compatible with both PHP4 and PHP5. Last time I checked, there were reported problems using the relevant PEAR modules with PHP5. Do people really have to have a conditional based on the PHP version number to get it to work correctly?
It's also imperative, which makes it a lot easier for many people to use than a functional language like Scheme.
He contributes to PHP's DOM stuff and uses XML alot in Bitflux CMS. Has done a number of talks on XML in PHP 5+ here: http://www.bitflux.ch/publikationen/vortraege.html - pay special attention to http://php5.bitflux.org/xmlonspeed/ and http://php5.bitflux.org/xmloncrack/
Reccomended headlines for next PHP fanboys posts:
:P
- 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 picture on your wall using McDonalds fries, average sized elephant and twenty years old issue of playboy magazine. Ok, I have no problems to use PHP for what it's intented - quick, dirty and unmaintainable html generators occasionally attempting to simulate functionality of even the most basic OO languages, but please - everything has its limits.
P.S. I occasionally do XML for living. And XSLs are simple.
Currently I'm wanting something where clients send standard HTTP GET request and then my scripts respond in XML. I'm not sure if this is considered a web service or not (because it doesn't have SOAP, WSDL and the underlying architecture of most web service). Basically its a hack. A hack that is meant to save LOTS of bandwidth. The problem space is very narrow and the clients perusing the service will be aware of the structure ahead of time. I don't -need- the overhead of a real 'true' web service.
The kicker? I need it to scale. I'm not looking to deploy it to millions of people, but ideally it could handle that if I continue to grow and just throw hardware at it.
What do(es) the script(s) do? The majority is simple database queries and updates. Pulling and updating data. I will manage to work in some authentication scheme, too. There won't really be any floating point or otherwise.
Basically I just need to handle lots of requests to the scripts and the database. I realize that means I need some heavy duty database systems on the backend. We're primarily concerned with the speed and handling of multiple clients. We're thinking of an open source database like MySQL or PostgreSQL. If need be, we will look at Oracle. I'm not the database guy so I don't decide on this.
We're looking for a lightweight solution that can SCALE easily given the hardware and bandwidth. We don't want to do any rewrites once we get going with the project (yes, its often inevitable, but ideally we could write once and focus on maintenance once it goes live). In fact, we probably won't have enough time to rewrite if we wanted to once the ball gets rolling--we'll be focused on other tasks.
However the question still remains for the frontend scripts. What can handle a ton of requests in a lean manner? Is PHP+XML the right solution for this? I'd love to hear some feedback for people who have done this.
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 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.
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, they were there, however, only for the simpleXML class.
in reality if you wanna build a php/xml cms, you're going to need to use php4.4+ and either write or use one of the many classes out there for actually parsing/writing xml.
This is exactly what XML wasn't designed for. XML is shit for flat data like this.
XML is good at representing documents. On XML's turf - well, all the lisp representations of HTML that I've seen are confusing and ugly.
Is that another way of saying that they deserve each other? *ducks*
I use a lot of PEAR Modules between both versions with no problem.
For instance, the XML_Parser, XML_RSS, Mail, and Mail_Imap all work fine for me in either version 4 or 5.
the only permanence in existence, is the impermanence of existence.
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.
Assorted stuff I do sometimes: Lemuria.org
You can write (relatively) imperatively in Common Lisp. In fact, Common Lisp was the first standardized object-oriented language.
I think the bigger issue is that syntax-less languages are hard for some people to wrap their minds around... and also other languages have adopted so many features of Lisp that the differences are less obvious than they were before. Python, for example, offers first-class functions, dynamic typing, garbage collection (of a kind), etc. And the standard library of Python makes it much easier to use for the kind of quick-and-dirty stuff that scripting langauges are famous for.
I should try writing a Python-like language with Scheme macros. I bet it would be faster than Python is now...
please visit here...
3 54632
http://www.sitepoint.com/forums/showthread.php?t=
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 greatest php5 version. examples in the php online manual often don't work. there are undocumented capabilites.
as a trick, you will likely find more information about xml when googling "javascript xml tutorial" or "jaascript DOM tutorial" - and then you can convert the code to php5 class style. it will often work.
it is pretty cool, but it is a pita if you are swinging in the dark. too much missing or bad information. not very many examples that actually work - or examples that work with php4 or eralier versions of php5 but won't work with php5. or examples that just plain don't work!
good luck!
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.
Purchasing this book also resulted in a regular flow of Sitepoint spam until I wrote an abusive email to their marketing department saying that I had most certainly never ticked any of their "Spam me to death" checkboxes and that I couldn't be any less interested in discounts on their books. Surprisingly, their response thanked me for the honest feedback.
At least it ended well
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.
Stop Computers/Cars Analogies on S
Here
It's brief but I hope it helps. It's a good book by the way.
Need a color? Try 100 random colors
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