On 3 Apr 2005, at 17:27, yuppie wrote:
Hi Florent!

Florent Guillaume wrote:
- all in all it's quite nice,

Well. It works for some use cases, but there is yet a lot to be done. Though its maturity is still alpha, it already contains a lot of cruft.

Yes, I think I'll be doing some cleanups in it if you don't object.
And probably apply http://www.artima.com/weblogs/viewpost.jsp?thread=101968 to the code in general... I really have a problem with Tres's style ;)

- writing the code for the import handler is really painful, I wish we could use an API like elementtree. Couldn't we include it ?

Could you please elaborate on this? What are the most painful parts? Why are they painful?

Finding how to write the import mapping. For instance I have this stucture:

<?xml version="1.0"?>
<directory kind="CPS Members Directory">
<property name="title">label_members</property>
<property name="schema">members</property>
[... more properties ...]
<entry-local-role role="Owner">python:entry_id == user_id</entry-local-role>

Which I parse using:

    def _getImportMapping(self):
        return {
            'directory': {
                'kind': {},
                'properties': {KEY: 'props'},
                'entry-local-roles': {KEY: 'elrs', DEFAULT: ()},
            'properties': {
                'property': {KEY: 'properties'},
            'entry-local-roles': {
                'entry-local-role': {KEY: 'elr'},
            'entry-local-role': {
                'role': {},
                '#text': {KEY: 'expr'},

And I have to do:

        dir_info = dconf.parseXML(dir_text)
        dir = tool.manage_addCPSDirectory(dir_id, dir_info['kind'])
        for prop_info in dir_info['props'][0]['properties']:
            dconf.initProperty(dir, prop_info)
        for elr in dir_info['elrs']:
            elr = elr['elr'][0]
            res = dir.addEntryLocalRole(elr['role'], elr['expr'])

All the intermediate [0] and ['elr'] are cruft I'd like to get rid of. Maybe it's because I don't know how to use it best...

Are you talking about the import handlers themselves, the configurator classes or also about export handlers?

I have a question about a pattern used in the configurator classes: many times I saw the pattern than only one configurator was instanciated, for instance TypeInfoConfigurator, and then in the loop the ZPT called by passing, for instance:
tic.generateXML( type_id=type_id )
and the ZPT itself passes back type_id to getTypeInfo. Why not simply have the configurator instanciated once per type, with the type itself as an attribute ? Is it just old cruft ?

The framework doesn't dictate how import handlers are implemented. Did you try to write an import handler using ElementTree?

Not yet, it was just a feeling.

I never used ElementTree, but after looking at the documentation I doubt it would be very helpful: ConfiguratorBase.parseXML() converts types, sets defaults and maps keys. If we use ElementTree we have to do that in an extra step.

I think it's just that I don't understand parseXML's approach.

- I like and will use the recently added EXTENSION,

Seems some people started experimenting with this feature and didn't report any showstoppers, so if there are no objections I'll backport the changes into the 1.5 branch.

+1 from me.

Of course this is just a first step. E.g. we need a way to specify and handle dependencies between profiles.

Yes I was thinking of that too.

- has anyone used CMFSetup to import/export content space instead of configuration space ?
- really, what about including elementtree ?

+1 if it makes things much easier, -1 if not. I like the fact that CMF only depends on Zope.

I'll wait till I'm more familiar with what we have now.


Florent Guillaume, Nuxeo (Paris, France)   CTO, Director of R&D
+33 1 40 33 71 59   http://nuxeo.com   [EMAIL PROTECTED]

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

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

Reply via email to