My former colleague Lukas Kahwe Smith recently gave me a update on what is happening with the PHPCR initiative. Readers of this blog might remember me make a brief mention of PHPCR and the Jackalope implementation. My initial response was that I was unsure of whether the idea would take off but now I am pretty impressed with what I heard from Lukas.
Lukas and his team from Liip AG have been contributing to Jackalope as part of a large custom, content-centric web application they are building for a client using Symfony2. Jackalope goes beyond standard relational database persistence by providing sophisticated content services like content hierarchy, tree traversal, versioning, and content staging — common weaknesses in homebrew CMSs.
I can see a number of benefits to a PHP developer using PHPCR
There is less to build than when working directly against a REST interface like Apache Sling. You don't have to worry about making requests and marshaling XML or JSON into programmable PHP objects.
Your code can store any type of data in the JCR (not just documents). Using CMIS would be a bit of a stretch for anything but document data. Liip has developed an object-to-JCR node mapping layer (called phpcr-odm. Part of the Doctrine project) that behaves like a PHP ORM service.
The persistence engine is abstracted so you can swap it out with something that meets your performance needs. Jackalope ships with Apache JackRabbit but there are also transports in the works for MongoDB and standard SQL databases. They should be mature by the end of the year.
If you are building a content-centric web application in PHP, and you find yourself doing unnatural things to a relational database to meet your requirements, consider using Jackalope or the Midgard PHPCR implementation (which is designed more for speed). You are probably already be using Lucene for search indexing, how much trouble can one more Java application be to manage on your infrastructure?