Am 29.06.2008 um 15:04 schrieb yuppie:
Some tools are ordered containers, the types tool might become
ordered as well. GS always specifies the order of sub-objects in the
I suppose you could bundle all the information into a single types.xml
file - like you can with skins but that then makes manual changes a
bit trickier - if they are ever required. I find the current system
where the file system mirrors the ZMI structure pretty helpful and I'd
actually like to see it extended for things like the catalog indices.
The biggest problem we have with this is when editing in the ZMI,
exporting the XML and putting the XML files in the right folders: you
get information from all the profiles in which case it's easy just to
work with the individual type and update types.xml manually. Not sure
how ordering fits in with this multiple profile setup but it would be
pretty fiddly implementing it on a per file basis.
Right now we have a relatively easy rule: Adding, moving or removing
sub-objects modifies the container, so these changes *always* have
to be specified explicitly in the container's file.
'id' and 'meta_type' in the per-item files are not really used.
Would it be an improvement to remove that redundant information from
the per-item files?
I didn't realise they were both redundant! I would only remove them if
they are also removed from the ZMI.
Worse, it's easy to forget, and no warning that there are "orphan"
Adding a warning might be an other solution.
This would be a welcome addition to GS in general. I know I'm not the
only who's been bitten by the fact that ZCML will complain bitterly
about missing stuff which GS is happy to ignore. It doesn't matter
that the only thing the two have in common is that they're XML. When
developing new content types you add you package in zcml and type
definition in GS. It would be nice if a type definition was expected
but missing that this was raised. This would work with either approach.
I'm pretty sure it's an easy fix to make types.xml and
workflows.xml optional (or even deprecated, though of course
workflows.xml also has bind information that should remain there).
All the information required for adding, moving or removing sub-
objects is currently stored in the container's file. Additional code
and complexity is necessary to extract that information from per-
Avoiding complexity is always a good argument!
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests