[Zope-CMF] Re: CMFSetup

[yuppie]

Hi!


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.


Cheers,

	Yuppie