Jul 18, 2011
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.
-
You can use PHP to build delivery tiers and other web applications using content managed in a JCR-based CMS (such as Adobe CQ5, HippoCMS, or Magnolia).
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?
Feb 10, 2011
I have been thinking a lot about Nuxeo's recent announcement that it is contributing Nuxeo Core to the Eclipse Foundation. First, I agree with Josette Rigsby's observation that this move could make Nuxeo the JackRabbit of CMIS. JCR watchers probably remember that Day Software's development of an open source reference implementation (Apache JackRabbit) was critical to the success of the JCR standard. Even though there are a lot of people questioning the success of the JCR standard right now, you can't argue that the JCR didn't have an impact on the Java CMS ecosystem and continues to be an important part of a number of Java CMS architectures. It would be quite a coup if Nuxeo was to be name that comes to mind when people think Java and CMIS. Alfresco has had that distinction since they were the early adopters of CMIS in the Java community and released the first CMIS implementation.
The other part of the announcement that intrigued me was why they went to the Eclipse Foundation and not the Apache Software Foundation. After all, Apache already has Chemistry, which is a collection of projects that implement the CMIS standard. My first reaction was that Nuxeo thinks the ASF is broken since its tiff with the Java Community Process. That may be so but I think there are better explanations. First, Chemistry already has a number of projects and it is still in the incubation stage. Perhaps Nuxeo feels that these aspects would dilute Nuxeo's influence. Second, Nuxeo has had a long relationship with Eclipse. Back in 2006, Nuxeo announced the Apogee project. Apogee is an RCP (an Eclipse build), designed to be a universal thick CMS client. Apogee never really caught on in the general marketplace, but I know that Nuxeo has been very successful implementing it for their customers as an efficient user interface for their own CMS. With the advantages of influence and the Eclipse Foundation's community and resources, Nuxeo Core may have great potential as the Eclipse Enterprise Content Repository Project (ECR).
Dec 09, 2010
Kas Thomas (from Adobe/Day) writes that a PHP port of the JCR (called Jackalope) is near completion. A big part of the project was to translate the JCR specification (which, like Java, is statically typed) to PHP's dynamic typing model. The result is a derivative specification called the PHPCR.
PHP developers have had access to JCR repositories for quite some time through Apache Sling (which puts a nice REST interface in front of a JCR). What Jackalope brings to the table is a PHP-based, in-process API that may be faster than hitting a REST interface. However, that doesn't mean PHP developers can totally forget about Java. The current implementation is an adaptor that connects to a JCR (Apache JackRabbit) through webDAV (so http is still in the mix too). The next phase of development will swap out the JCR storage backend with a basic database thereby removing the JVM from the picture entirely.