Thanks for the feedback - I hadn't looked where you suggested, and I'd been
thinking about starting with the catalog, so I managed to avoid two
potential pitfalls before starting (very pleasing!).
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
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
- 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).
- 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.
I'm sure I had another question, but I can't remember now...!
Use MSN Messenger to send music and pics to your friends
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests