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
- 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