Long time since I updated this (well, two weeks or so), but I had a short holiday of a week. And I ran into severe zope vs. rdflib biting...
Back from holiday

Just got back from a one-week holiday (Texel, the Netherlands). I've
kept the nagging feeling that I did something wrong with removing the
actual rdflib store to a local variable instead of subclassing all the
rdflib functionality.

Some research made it clear that subclassing existing classes in zope
isn't that
easy. You
need a few workarounds. So in the end I kept that store local
variable. Rdflib uses the new-style-class's super() method a lot and
that is stopped dead in its tracks by ExtensionClass. And
ExtensionClass is deep in zope and used by acquisition... I better
just admit defeat and keep rdflib a bit apart from the zope
aparatus. Zope 3 promises to be much better in this regard, however.

Adding an icon proved to be simple. I created www/rope.gif and added
icon = "www/rope.gif" to __init__.py, just after the line with the
constructors.

Also I added a page template. I created them in skins/default. The
first one is 'rope_view.pt':

Now index_html is rendered according to the page template, getting rid
of hardcoded html in the code. Separation of logic and layout is a
very good thing.

Biting the bullet: removing new-style classes

Well, in the end there was nothing to be done about it: either zope's
extentionclass mechanism goes out or the new-style classes go out. As
zope is much bigger than rdflib I decided to remove the new-style
classes from rdflib :-)

For this I copied all imported rdflib files to the root directory of
my product, removing all rdflib. thingies to make sure the local
version of the file is loaded instead of the installed rdflib
library. Putting everything in the product's root directory feels very
sloppy to me, but subdirectories don't work in this case. An import
subdirectory.filename sends python to look for a library
subdirectory instead of having him look in the subdirectory. Ah
well.

A small positive point in all this mess: in this way you don't need to
install rdflib seperately, it's all one self-contained package.

To get meaningful error messages I added the following to the end of
rope.py. This way I could do a python rope.py and get a few
errors:

Copying the files and first clean-up

Look at the rdflib imports in the .py files present (only rope.py
at the beginning).

Change those imports to local files by removing the rdflib. part
(and other subdirectories if present).

Run python rope.py and see what it's complaining about.

Copy the missing files and repeat the process.

There are some points at which you encounter name clashes. For
instance from rdflib.syntax.parser import Parser doesn't give a
problem, but from parser import Parser imports the parser from some
python or zope standard library. In a case like that I renamed the
file from parser.py to rdflibparser.py. The same with
rdflibexceptions.py. Sometimes you need to remove all *.pyc files
also. Renaming parser.py doesn't have any visible effect on python's
complaining when parser.pyc is still available (yes, I had that
problem, it bugged me for 10 minutes).

Removing object class

New-style classes subclass from the object superclass. A grep class
*py | grep object will reveal the culprits (or at least most of
them). Next I removed that object-subclassing from the files.

At this moment I got rid of "metaclass error" messages when running
python rope.py!

Removing super() calls

super() is used a lot by rdflib in order to coordinate the various
__init__() methods, as rdflib uses subclassing a lot. It is also
used in other places, but __init__() is the most common here.

This was actually quite a precision job as I had to call the
superclasses' __init__() manually now. This means looking very
carefully at the inheritance hierarchy and at the needed arguments.

Explanation: NTParser doesn't have a meaningfull init method, so that
one doesn't have to be called (I removed NTParser's __init__()
later). Parser hasn't got an init method, so only serializer is
left. That one is called.

It's an iterative process of running python rope.py, seeing where
python complains and then correcting that super() method. This way
you won't miss anything. My guess is that in this way you follow a
remotely useful path through the source files.

At one moment I ran out of error messages (yahoo!!!) so I added
another line to the test function:

rope.store.add((ns['a'],ns['b'],ns['c']))

Hm. The error message I got didn't concern super() errors. Ok. While
there are still a few super() calls left in the software, none of
them directly interfere with the zope mechanism. Perhaps something
doesn't get stored in the zope database, but I'll worry about that
later.

The current set of errors centers around properties. Another new
thingy with new-style classes. You say "this is a property, but use
these two methods to get/set the data". Which probably means that this
mechanism doesn't work when you just removed the subclassing of
object from the class. I printed the new-style classes
documentation. Reading fodder for the train home :-)