How not to build a view

I like simple, sweet, and easy to use. Which means sometimes Zope 3 style things are awesome, and other times it sucks. What's worse is implementations you have to maintain where someone took something very simple and made it very complex.

In our case study, lets see what a predecessor to me did using Plone and a lot of Five:

1. Extended the ATEvent type.
2. Created a view using portal_catalog. This creates an object which calls another object which calls a specific function to grab relevant data from each brain object and place that data in a dictionary.
3. Made the view, 2 objects and functions bolded above not as extensions as other bits that existed elsewhere but coded them individually.
4. Tied it together with zcml.
   

The end result was a results object containing brains and a counter. Um... okay. I understand this was done so that the Plone template serving this would have the batch features and all, but this is over engineering.

I think a better solution would have been this:

1. Extend the ATEvent type.
2. Create a utility package with code to be reused in creating batches later.
3. Make the view call the utility package so you don't have to code much.
4. Tie it together with zcml.

I like this method. The better developers I work with and the gurus I admire will tell you any time you write the same section of code more than once you should look at code reuse techniques. Either wrap your code in functions, use inheritence, or play with polymorphism. All that good stuff.

Sigh.

At least I get paid to maintain this code. Finally it isn't in the NASA effort.

Our NASA Plone project launches

http://nasascience.nasa.gov

This represents the work of about 20 people or so in many areas. Some details:

• Plone, Zope, and Python application stack
  
• Served by Apache and cached by Varnish
• Section 508 compliant and meets usability requirements
• Valid XHTML, so you can easily write stuff to hit it
• Lots of custom views.
• Lots of imported plone products
• Several custom plone products
  
• Hitting the mass media now.
  

Plone Introspection

So you have a Plone content type with some fields. What are the properties of that content type? Well, you can look it up by finding in your file system the product that content type comes from, then examining the schema and finding out your information. Of course, if the product extends another product, then you have to look up that other product.

Bleah.

Introspection is what we really want. Python has it in spades. On pretty much any object in Python I can wrap it in dir() or help(), or check the __dict__ attribute. But you can't do this easily in Plone. Cooking up a universal instrospection view is something that ought to be done for my CMS of choice. I know there are lots of various barely documented utility methods I can find. I can wrap it up in a product and just use it by having a special introspection view that lays out some pretty HTML.

Sigh.

My coworker Reed pointed out that Zope 3, and the Five stuff in Zope 2 uses Interfaces that give some neat tricks you can do for introspection. I think I'll give that method a try. I think thats the right way to go because:

1. The Zope 3 specification handles introspection much more gracefully than Zope 2. And the methods for doing it seem better documented.
2. The technology is going that way anyhow.
   

Image of the Day 'extension' of FeedFeeder experience

Introduction

For a huge work project I was asked to extend FeedFeeder so we could have an image of the day type. I like FeedFeeder and this would give me the chance to speed up on Five and Zope 3. I was so excited! Five turned out to be lots of fun and not that hard to learn. Zope 3 Products looked like tons of fun, sort of like Plone products on steroids or J2EE done right.

And yet the effort turned into an exercise of frustration. Why?

The thing I like about Plone (and now Five / Zope 3 (Z3)) is that once you grok something, it is really easy to make new content types or extend new ones. You can do that via UML using ArchGenXML, or simply code it out yourself. I really enjoy this part of plone, being able to handle new content types so easily.

Things go downhill

Alas, FeedFeeder is a weird amalgam of ArchGenXML output and Five technology. ArchGenXML generated a lot of the boilerplate, but then the authors went and did things in all sorts of weird places that violate what you are supposed to do with ArchGenXML output. It is very obvious that FeedFeeder is the designer's method of learning and Five and component based design. Which is nice, but what you get is something that is very hard to extend and control. By combining ArchGenXML and Zope 3 and Five the way they did, it is actually more work to make it do what we want.


Normally adding a new content type in Plone / Five / Zope 3 / ArchGenXML, you just extend/implement an existing content type and modify either a ZCML (Z3, Five) or Install.py (Plone) or AppInstall (ArchGenXML) and maybe stick in an adapter (Z3, Five). Well, not so much in FeedFeeder, where to add an extended/new content type you have to modify the following: configure.zcml, install.py, and pretty much rebuild the content type from scratch. Then add in views and skins. Then pray it works. Just getting a simple extension without any modification to work was looking to be way, way to much work.

After working on it for hours yesterday at CC, and an hour last night, and during the wee hours between 3 and 5 am when I thought I had an epiphany, I was getting really frustrated. This wasn't like association classes where I knew that if I could just find the right bits in the lackluster docs it would work, I really felt like I was walking through someone's spaghetti code.

The Recovery

So I start thinking about building my own product from scratch to do the work. This annoyed me. I hate reinventing the wheel. Oh well, time to take notes on what it was doing. And I discovered right away that Feedfeeder curiously had something called enclosures. I researched it out, and you know what? Enclosures where a way to include content in Atom and RSS feeds.

I tested it out. I created a set of sample Atom and RSS feeds with enclosures with images. Then I created a FeedFeeder folder called 'iotd feed' to grab them. Then I check, and FeedFeeder grabbed the images and stored them as enclosure objects!

POW!!! Done!!! Feedfeeder does it already! All we need to do now is create a smart folder or view that looks for the 'iotd feed' folder to supply image of the day views!

Notes & Lessons learned

• I'm still not happy with FeedFeeder's internal architecture. But since out of the box it does everything we need and probably more, do we need to care?
• When I hit a brick wall like this I need to do more research. Especially when it comes to something that is using a standard. For example, I need to get a 100% understanding of something before I start trying to invent something new.
• Time Summary:
• Time spent learning Five: 1 hour
• Time spent playing with Zope 3: 2 hours
• Time spent trying to extend FeedFeeder gracefully: 4 hours
• Time spent extending FeedFeeder via gruesome hacking: 2 Hours
• Time spent examining FeedFeeder for things needed in a new product: 15 minutes
• Time spent researching Atom/RSS for how they handle enclosures: 5 minutes
• Time spent testing out how FeedFeeder handled enclosures: 15 minutes
• Total Time: 9 hours and 35 minutes
• Lesson Learned: Do your @#$%ing research before you commence work!

Interfaces in Zope 3 and Five

We use Plone a lot on the job. And Plone is leaning towards Zope 3 these days, which means Interfaces (thanks to Zope 2's inclusion of Five)! Until now I've not had a reason to really poke at Interfaces, because Python, unlike Java, doesn't really need them. Also, the Plone work I've done so far has been via UML, external methods, views (ZPT), and fancy install scripts.

However, now I'm working with feedfeeder, a Plone ATOM/RSS handler and we need to extend it to include an image-of-the-day content type. And feedfeeder is built with a lot of Interfaces and Five technology.

Alas, I don't have a Zope 3 book handy here at work.

Until my copy comes in, I'm using the Zope 3 tutorial created by the Zope 3 book author. Good stuff indeed. I'll post my thoughts when I'm done.