computing project wrote:
I've written handlers for the cookie crumbler and for the mailhost - not exactly rocket science but actually very informative as they are pretty simple (well, the simplest!) tools. I started off looking at all the code, and found that I didn't need to look at most of it to get things working. I also feel like I've also come up with a bit of a methodology that's useful to follow when trying to write handlers, so I will write up a brief HowTo at some point - grateful for some feedback on this. No unit tests yet though...

Great! Copy'n'paste and search'n'replace are your friends if you want to create unit tests ;) The handler tests are all very similar...

Some vague questions though:

- in what way is the setup tool code 'likely to change'. i'm interested to find out more about what's planned, and also how to make the setup scripts less brittle?

Looks like the setup handlers registered via export_steps.xml and import_steps.xml will be replaced by adapters. Tres is working on a proposal for that and the portal_catalog code in my sandbox also uses adapters. This means that handlers will have to provide a new interface.

Besides of that I'm experimenting with reading / writing settings directly from / to a DOM fragment. The result is less code that is hopefully easier to write and maintain.

Other handler related issues that come to my mind:

- We need a reporting/logging machinery (seems to be covered by Tres' proposal if I interpret his example correctly). Handlers have to be more verbose.

- We might need more import modes, currently just 2 modes are supported: "purge" and "don't purge". The behavior for these modes has to be implemented within the handlers.

All these things still have to be discussed.

- i found it tricky that i couldn't look at some sort of schema for the inout/output of an import/export step: there is some information which is only captured in zpt templates. is this something useful to think about more? i also wondered if attaching types into the schema would make the import configuration simpler (e.g. i could specify in the schema that a property should be interpreted as an integer, and not in the import configurator: which would make it easier to read).

The dicts returned by _getImportMapping() have a proprietary format but they are similar to schemas. We can't use those dicts for exporting because zpts don't allow to use dynamic element names.

Given the variety of object factories and mutators in the CMF/Zope2 world I tend to get rid of any framework for importing/exporting XML and to manipulate/read the DOM directly.

- in cmf core + default, the mailhost is just referenced by self.MailHost. Should this be a getToolByName? and/or should the MailHost be a unique object so the id doesn't change? and should we always assume it's a child of the portal object? i wasn't sure what the 'correct' way to reference it was, to ensure it was available to import.

MailHost is a Zope "tool", not a CMF tool. If we don't want to subclass MailHost we can't use UniqueObject. But using getToolByName() sounds like a good idea.



Zope-CMF maillist  -  Zope-CMF@lists.zope.org

See http://collector.zope.org/CMF for bug reports and feature requests

Reply via email to