Plone Web Services: Things are Looking Up
A History of Less Than Ideal Solutions
Plone’s web services story has been a mixed bag. On the one hand, it has always supported XML-RPC (included in Python’s standard library since 2.2), a protocol that provides remote procedure calling using HTTP as the transport and XML as the encoding. This is a simple, minimalist, and easy to use way for a Plone site to publish or consume data via a web service. Just write a Python Script or External Method that inputs or outputs a list, dictionary, integer, string, date/time, or boolean, and it can be used anywhere on the web, from any language that has an XML-RPC library (and that’s pretty much every language in use on the web today).
This is powerful and flexible, but it isn’t a “Plone Web Services API” – it’s a mechanism to easily write a custom web service API for a Plone site. For example, a Plone site with biographical data about U.S. presidents could provide XML-RPC methods like getPresidents(startdate, enddate), getBirthDate(president), getInaugurationDate(president), etc. But Plone doesn’t come with a set of generically useful XML-RPC methods like getObject() or getTitle().
The other problem is that XML-RPC is not a mainstream web services protocol, like its successor SOAP which is much more complicated, but embraced by industry. And if you’d like your web services to be RESTful – well, no RPC protocol is RESTful. In fact, Plone can’t do REST-style services at all because the Zope 2 publisher only provides HTTP GET and POST. There won’t be truly RESTful web services in Plone (with support for HTTP PUT and DELETE) until the Zope 2 publisher is retired.
Several projects have tackled improving the Plone web services story by providing a uniform API for getting XML representations of Archetypes content objects:
- CIGNEX implemented SOAP web services for a customer
- The ATRest product used Marshall to generate XML representations
- The GSXML product used Marshall and GenericSetup to generate XML representations
But none of these gained momentum as the Plone web services solution. So when Michael Mulich and Kevin Kalupson at Penn State tackled this problem last spring, they went back to basics.
Roar of the WebLion
The WebLion folks had gotten numerous requests that lent themselves to web services solutions.
- Keep selected content – such as events or news – on 2 or more Plone sites in sync
- A desktop application that consumes Plone content
- A web site that would present Plone content in an Adobe Flash skin
Michael and Kevin decided to solve all these problems with a simple web services API that provides a standard CRUD (create, read, update and delete) interface to Plone content. And because it is so simple, flexible, and available, they chose XML-RPC as the protocol.
The result is wsapi4plone.core (alpha release available on PyPi). Once installed it provides the following XML-RPC calls on any 3.x Plone site:
- post_object
- put_object
- get_object
- delete_object
- get_workflow
- set_workflow
- query
- get_types
- get_schema
With this it is possible not only to mash up bits of Plone content in a web application, but to allow full read-write communication between Plone and another web site.
Atom Publishing Protocol
Although wsapi4plone.core solves the problem, it does not do it in a truly RESTful way. This is the holy grail set forth at the Plone Strategic Planning Summit and discussed at length at the 2008 Plone Conference. The conclusion of these discussions was that Plone should support AtomPub as its web services API – someday when the limitations of the Zope 2 Publisher are removed. For now, the best we can hope for is a separate component that would act as a middleman providing an Atom Publishing Protocol interface to a Plone site.
Google Summer of Code to the rescue! Two of the seven SOC 2009 students are working on a WSGI middleware application that does exactly that. It is called wsapi4plone.parfait, and it will use wsapi4plone.core for its communication with the Plone site. The process looks like this:
This project is a trans-Atlantic collaboration between:
- Mike Mulich (Robert Morris Unversity student) and Kevin Kalupson (Penn State mentor)
- Chelsea Bingiel (University of Chicago student) and Matthew Wilkes (Team Rubber mentor)
You can read more on its CoActivate web page, and you can check out the source code at https://dev.plone.org/collective/browser/wsapi4plone.parfait.
To the Future and Beyond
The SOC project and wsapi4plone.parfait look like the future of Plone web services. With an AtomPub interface to Plone, interoperability with other frameworks becomes possible, especially given the work that’s happening on CMIS (the new Content Management Interface Specification OASIS draft standard). Let’s all cheer the SOC team on!
Creating tabs part 1: Using Plone, Kupu and jQuery
One of the requirement for the Oxfam America project was to provide a method by which content editors could update and edit the tabs that comprised the home page. For editorial reasons, thhe number of tabs would be variable as well as the content. While other sections of the Oxfam America site use queries and site structure to generate tabbed UI elements (will be explained in follow up post), there was not a clear way to reuse these existing solutions for home page.
We initially considered the following solutions:
- Linking the home page tabs to content items located in another section of the site. Those content items would provide the necessary text for populating the tabs.
- Creating either specific content type with enough configuration to handle the various tab layout options.
Approach 1 had the immediate disadvantage of breaking up the content editing into multiple steps and locations, increasing complexity for the end user. The second option would have broken the separation between the storage and display of content. In other words, while the site currently is using tabs as a means to provide more content density per pixel, there is no guarantee that tabs will remain a long term solution. It is a certainty that UI elements and strategies will continue to evolve; today’s tabbed based UI will be supplanted by something else in the future. Thus we wanted to avoid tying the structure of the content to a particular visual layout or theme.
So what to do…..
We briefly contemplated doing something clever, but clever meant a fair amount of custom work with JavaScript, plus getting it to play well with Kupu. Fortunately someone in the community had already solved this problem. Enter Mikko Ohtamma’s collective.kuputabs
This tool uses the following approach:
- You define a set of custom classes to indicate where each tab should begin
- Use jQuery to render tabs based on the custom classes for the public view
This is probably best demonstrated visually, here is a short video showing how it works. It demonstrates the creation of a new tab element and the transformation of that element from the editing interface to the public view.
So three cheers for the community again, if you are interested in other strategies for incorporating javascript and Plone you should also check out Products.pipbox.
Jazkarta Blog 