Inez Becomes a Plone Developer
With a little help from Archie and Jasper.
A few years ago, Martin Aspeli wrote a great blog entry, Pete and Andy Try Plone 4, describing how two (fictitious) IT consultants named Pete and Andy evaluate (then also fictitious) Plone 4.
Well, years have passed. Plone has moved on to a real version 4.2, and nearly everything in Martin's vision is now available. Pete has become a manager, and never gets to code. Andy got hired away by Mozilla. Pete hires a Python coder named Inez to take over the code-monkey work for the company.
Inez has been a proud Django coder, and is a bit freaked out about Plone. She's heard it's hard to get started developing and that you need to learn obscure computer sciency stuff about interfaces and adapters. She's also worried that if her Python friends hear she's now a Plone developer, she'll be ostracized at PyCon. But, she's going to give it a try because it's still Python, and she could never live with herself if she had to write PHP.
After she gets her employment paperwork done, Pete sends Inez to meet first with Archie, a designer, then Jasper from Operations. Archie's going to show her the new site design, and Jasper's going to tell her about the content types the company needs implemented.
Design. Inez expects Archie to show her photoshop compositions of the new web design. Surprise! Instead, Archie shows her a working site with the new design. Archie explains that he prototyped the site design with Photoshop, then converted it to HTML and CSS. Archie then implemented it in Plone using a few "Diazo" rules in XML to map Plone content onto the designer's unaltered HTML files. (Inez is horrified! "Diazo" — already the Plone-specific vocabulary is filling the air.) Archie's already run usability tests and gone through a couple of design iterations with the designs running live on Plone.
So, what's left for Inez? Archie points to several page components that need futzing — text moved, different fields displayed, content aggregated, that sort of thing. Inez is going to need to find and customize the templates that generate these components.
Content Types. The meeting with Jasper, the ops guy, is shockingly similar. Inez expects to see something like crude UML diagrams, which she'll need to convert to a relational database design and a bundle of SQL. Then, it'll be on to worrying about how to prevent SQL injection attacks.
Instead, Jasper shows her impressive simulations of content-entry forms. They're even using the latest version of the new site design. Just before she asks a question about what's being used for the simulation, understanding dawns on Inez: Jasper is actually using the same development Plone install that Archie showed her.
Jasper explains that he has already set up the new content types through the web, using something called the "Dexterity schema editor." (Ack! "Dexterity" — more Plone jargon!) He's even run the schema past all the folks that will need to be entering content with the new types, and adjusted the schema to match their feedback. Punchline: Jasper's new Dexterity content types actually create content items in the Plone object database.
What's left for Inez to do? Jasper tells her the forms need a lot of data validators added. Some of the selection widgets will need to draw choices from other parts of the site or use vocabularies that Jasper wants to be able to edit through the web. Parts of the data from the new content will need to be searchable, and parts will need to aggregate to the site's home page.
Inez is reassured to discover that there's really lots of code to be written. Also, it's good to know that all that nasty Plone complexity is still waiting for her, so she'll have great war stories to tell at PyCon.
Before the fun stuff gets going, Inez is going to need to get a working copy of Plone going. Everything she's heard about Plone tells her this is going to be awful.
Hmmm. Not that bad. Inez reads a Plone.Org page and concludes she should start with something called the Unified Installer. She downloads it and unpacks it into a test directory. Inez checks out the ReadMe (something she only does when her testosterone-poisoned male coder friends aren't looking), and figures out that she can just run an install script with a command-line option to use the "developer" profile. It takes a few minutes to set Plone up, and she has it running and is looking at an empty Plone site about a minute later. (Remember, Inez read the ReadMe; experience may vary.)
Inez begins to suspect that the horror stories she's heard about Plone installation must have been spread by PHP types who confuse Apache with an operating system.
Content Type Implementation. Inez does some reading on Plone.Org and figures out that the next thing she wants to do is create a Python package that will allow her to code the guts of Jasper's content types. She's read the developer ReadMe installed at the top of her new Plone install directory and learned that there's a skeleton-generator to create a Dexterity add-on package. Skeleton generators seem perfectly reasonable to Inez' Django-trained mind. (But this one's called "templer" — again with the yucky, Plone-specific vocabulary. Oops, turns out Inez needs to take that back. Turns out that templer's not Plone-specific.)
This is the first fiction in this post. Templer does not yet add newly created packages to buildout.
Inez runs "templer dexterity" from the command line and answers a few questions. Templer builds the skeleton and drops it in her "./src" directory. The ReadMe tells her it's already set up in the installation's configuration file, buildout.cfg, and that she just needs to run "bin/buildout" to finish the integration.
Inez cranks up her editor and checks out the skeleton of her new package. There's a ReadMe that tells her what all the parts do. There's even a testing framework built in!
Inez can run templer again to create code code skeletons for her new content types. She also discovers that she can import Jasper's model to lay out all the fields. A quick email exchange with Jasper, and she's got a zip file containing XML models of the field layouts. All she has to do is unpack it into her "models" directory and rename the XML files to match the class names she used when she created the content types.
Inez restarts Plone (which is suprisingly fast; what happened to those slow startups her friends warned her about?) Being the type who actually reads the ReadMe, Inez knows that she now needs to navigate to the add/remove add-on packages configlet and activate her new package. Wow! Jasper's new content types are all installed and available on the "add" menu.
Inez has not yet written a line of code and the whole infrastructure for the new content types is in place in Plone. Time to write code, though, and Inez knows the Plone horror story must be getting ready to start.
Inez opens the generated source file for the first of her content types — and her anti-Plone side is pleased to see that it looks a bit cryptic. Interfaces! She's going to have to drink the Zope kool-aid! But, at least there's a comment block that basically says "put your validators and other schema support code here," and points her to an online Dexterity tutorial.
OK, writing validators and dynamic defaults isn't that hard. Inez does have to use Python decorators though, which she's never understood and always seem like a gross violation of Python's "no magic" zen. At least they work.
Inez makes a cool discovery: her code editor, Sublime, is doing code completion and browsing for the Plone library modules. Amazing!
Vocabularies for select boxes aren't so easy. Since they require information from other parts of the site, they have to establish context. It also turns out to be the time she has to learn something about interfaces, since it turns out that these are used as discriminators for finding the other content she'll use to establish one-to-one and one-to-many relations with other content objects. Fortunately, there are good examples in the Dexterity tutorial.
Inez also has to figure out at this point how to read and edit Dexterity supermodel files. XML! Does anyone like to use XML for configuration? At least it works. Inez also understands from the tutorial that she can do the same chores with Python in the content type .py file. But, she can put off learning Zope schema until another day.
Finally, Inez needs to adapt the presentation templates for the new content types, which are conveniently located in content_classname_templates directories. Unfortunately, this requires learning Yet Another Template Language. No getting around it, something new to digest. But, at least it's HTML-based, and she doesn't have to go home with that dirty feeling that comes from mixing program logic with HTML. Instead, she learns that she can write the real guts in plain-old Python in the source file, and it becomes part of the environment for the view template.
Several days have now passed, but the content types are now well past the prototype stage. Jasper's pleased with the progress. And, the test coverage is complete, which makes Inez feel like she's on top of the world.
Design adaptation. Time to learn Diazo. Thank the coding gods, there's another developer-oriented tutorial for this. Inez begins to see how Diazo is fine for designers. But, she knows that XSLT is under the surface, and those four letters make her queezy. She tried to figure XSLT out once, and it was far too recursive and tricky for an honest Python programmer's taste.
Following the Plone.Org tutorial, Inez returns to templer to generate an add-on package to contain the Diazo theme. She asks Jasper to export his rules and resources. He sends a zip file and Inez unpacks all that into a "rules" directory in the new package. Once again, it's time to run buildout, restart Plone and activate an add-on package. But, once that's done, the new theme is immediately live, and, thanks to Jasper, not looking bad at all!
Now, Inez turns to those page components (viewlets and portlets in Plone's bizarre jargon) that need tweaking and coding. From the theme-development tutorial, Inez learns that her starting point is to copy the existing templates into path-coded names in the add-on packages "jbot" directory. ("jbot!" Will those Zope/Plone people never stop creating weird new terms?)
This requires finding the original templates. The tutorial helps her find them, but Oh! My! Plone has a lot of packages. How can any Python application have so many packages? Inez begins to realize all the complexity that buildout has been hiding. She also realizes that while the complexity is definitely there, she hasn't had to dive into the deep end yet.
The templates use the same markup method she learned when doing the content-type presentation templates. That goes faster now.
Things get a bit scary when she hits the point of needing to aggregate some data from the new content types. But, what do you know, it turns out that this doesn't need any code at all. She can use Plone "collections" to aggregate the data, and then present it in a collection portlet.
Inez realizes that she has not had to write one line of XSLT!
This does, though, require Inez to return to her content types, as she's going to need to index some parts of her content object data into a peculiar Zopish beast called the "portal_catalog". It turns out that it's possible to do that just by adding an XML file to content type's profiles directory, and doing a bit of annotation in the supermodel files. Inez needs to read the Dexterity tutorial's section on this about three times before "Generic Setup" begins to make sense. But, it's documented, it works, and she is able to get it working without swimming too far into the deep end of the Zope/Plone pool.
Again, several more days have passed. But both Archie and Jasper are happy. Pete asks Inez to join a meeting to talk about the next site project.
The Next PyCon
Some things don't change.
At the next big get together with her Python BFFs, Inez regales them with horror stories about Plone: Diazo, Dexterity, supermodels, interfaces, schemas, oddly named skeleton generators, XSLT, JBOT, viewlets, portlets, catalogs, and Generic Setup. Her friends laugh uproariously and are reassured that Plone is on the wrong path. All is right with the world. Inez feels guilty about reinforcing the old Zope phobias, but knows that if she didn't she'd be a pariah.
What's real, and what's fiction?
What's truly impressive about Plone 4.3 (in alpha 1 as I write this), is that nearly all of the moving parts are already working. What development remains?
- Templer is still in development, and the dexterity and diazo skeletons need work to do everything described;
- The Unified Installer does not yet have a "development" mode — though it does generate a develop.cfg buildout configuration file. The "develop" profile need to have some things like automatically setting up templer and adding the code browsing/completion setup.
- The Unified Installer and our templer skeletons need to be set up to work well enough together that it's possible to add development packages and have them automatically added to buildout.cfg.
The biggest fictions are about documentation. Pretty much any place that Inez was able to figure out what to do by referring to a tutorial was gross fabrication. So, shall we fix that?
I'm hoping to sprint on these items at the Plone Conference. Unfortunately, Inez, Freddy and Archie won't be able to make it this year.