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 container's file.

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" files.

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- item files.

Avoiding complexity is always a good argument!

Charlie Clark
Helmholtzstr. 20
D- 40215
Tel: +49-211-938-5360
GSM: +49-178-782-6226

Zope-CMF maillist  -

See for bug reports and feature requests

Reply via email to