[Zope-CMF] Re: CMFSetup comments
Florent Guillaume
fg at nuxeo.com
Sun Apr 3 12:07:32 EDT 2005
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">
<properties>
<property name="title">label_members</property>
<property name="schema">members</property>
[... more properties ...]
</properties>
<entry-local-roles>
<entry-local-role role="Owner">python:entry_id ==
user_id</entry-local-role>
</entry-local-roles>
</directory>
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)
dir._postProcessProperties()
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
--
Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D
+33 1 40 33 71 59 http://nuxeo.com fg at nuxeo.com
More information about the Zope-CMF
mailing list