Core

Thanks to Tres Seaver (who applied my fix to the various Zope and Five branches), the barrier to merging the maurits-traversal branch to trunk is now gone.

Also, as Jon Stahl pointed out on the Quills-Dev mailing list, it would be a good thing if quills.remoteauthoring was made to work with standard Plone content types, not just the specific Quills Weblog type.

I'll be working on the merge-to-trunk and extending the application of quills.remoteauthoring soon.

Traversal Security Bug

First, I think I have partly tracked down what the security problem is that requires the use of __allow_acess_to_unprotected_subobjects__ on the archive and topic classes. After another pdb session, it seems that those classes do not have a __roles__ attribute, which the Zope security machinery wants, apparently. Actually, I think it's more than that. Even when I add a workaround of __roles__ = Acquisition.Acquired (so that the attribute is just picked up from the next persistent object it finds), things don't work properly as the security machinery chokes a little further down the line.

My best guess at the moment is that InitializeClass isn't getting called (properly?) by the Five ZCML handler for this. That's my next avenue of investigation.

Remote Authoring (aka MetaWeblogAPI)

The other news is that I've started refactoring the MetaWeblogAPI support into separate packages that implement the API with a view rather than a persistent subobject of Weblogs. This should make it easier to disable the functionality, and easier to apply it to alternative content types.

As things stand, I have a PAS IExtractionPlugin that gets user credentials from a MetaWeblog request, and a view that is largely a copy-n-paste job from the existing MetaWeblog implementation.

Some issues remain, though. While I can add the blog successfully with ScribeFire (nee Performancing) - which means at least one MetaWeblogAPI method is getting called without problem - attempts then to get category listings or otherwise use the API fail with a security error.

None of this is checked in to svn, yet. I will do so as and when it gets a little more polished.

I haven't made any Quills checkins for the past couple of days, so I thought I'd explain the current status of my main development branch (maurits-traversal).

As I mentioned before, there is now a hard dependency on Plone 3.  After chatting to Derek Richardson about his work on Vice, this seems even more inevitable as that is likely to have a Plone 3 dependency as well.  (Vice is the new, improved, outbound syndication code that will replace base/fatsyndication as soon as it's ready.)

So, onto the current specifics of the maurits-traversal branch.  WeblogArchive has been removed and posts are now stored directly within the Weblog object.  This means that the "evil" workflow that would cut-and-paste weblog entries into a hierarchy of archive folders is now gone too.  Yay!  The previous folder hierarchy of the form "[weblog]/archive/2007/06/13/entry_id" is now `faked' with an IPublishTraverse adapter.

Not only is the banishment of "evil" inherently good, but removal of the custom workflow makes it possible to be more Plone-ish in the operation of a Quills blog.  The use of standard Plone author/editor roles should now be possible as weblog entries don't need to be (implicitly) deleted during the publish step.  So, the WeblogAuthorRole should now be superfluous.

The main thing stopping me from merging this branch to the trunk is a security issue that means it is necessary to declare __allow_access_to_unprotected_subobjects__ = True on the (non-persistent) topic and archive classes.  This is obviously a bad thing as it competely circumvents security.  For some reason, security and/or the acquisition chain seems to get a bit screwy when the new plone.portlets code gets invoked.  At first, I thought this was something to do with my traversal of non-persistent, non-standard-plone, objects, but Martin Aspeli recognised my traceback as something he's trying to chase down in a different context (pardon the pun).  Hopefully, he can figure out what's going wrong as I've been all through things in a pdb session, and am still none-the-wise.

The other notable change on the branch is that QuillsTool has now been removed.  In its place is a view that has all the same methods, plus some extra ones factored out from over-complicated skin templates.  I'm not completely convinced that the view is the right place for all these methods, though, so a utility may grow back at some point.

The upshot of all this is that the maurits-traversal branch should be in a state for people to check out and give a test run to (as long as you understand it is pre-alpha).  Migrations are not there (yet), so you'll have to use a fresh instance.  Unit tests almost certainly don't pass, either.  They probably need quite a lot of work after the major surgery that has happened...


That's it for now.

For the past couple of days, I've been working on updating my main development branch (maurits-traversal) to be compatible with Plone 3.  This means being compatible with Zope 2.10, which in turn means that I have had to change the traversal mechanism applied to URLs like "[weblog]/topics/..." over to use the new IPublishTraverse interface and design.  As IPublishTraverse is not available in Zope 2.9.x, this amounts to a new hard dependency for Quills (1.6+) on Zope 2.10 - which presumably means a hard dependency on Plone 3+.

A few notes on the new IPublishTraverse mechanism are in order.

First, it took quite a long time to swap things over, although this was largely because it took me a while to figure out what I was supposed to do.  Maybe there are docs, but I coudn't really find them.

Second, the IPublishTraverse is, for my purposes, not as nice as what went before.  My goal was to be able to intercept all URL segments below "topics" in "[weblog]/topics/Football/Tennis/Zope", and thus get the kind of traverse_subpath behaviour that "Script (Python)" objects have.  In the old setup, your traversal adapter was passed "furtherPath" as a parameter, and this would look like "['Football', 'Tennis', 'Zope']".  Easy enough to intercept the rest of the path, then.  In the new setup, the IPublishTraverse.publishTraverse method only gets the individual URL segments one at a time.  To get around this, you have to grab hold of "request['TraversalRequestNameStack']" directly - and that feels a little bit wrong.  It appears I'm not the only one who thinks this.

Ho hum, traversal (at least) seems largely to be working now.