[Zope-CMF] Re: Why do we need types.xml and workflows.xml?

[Charlie Clark]

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
--
Charlie Clark
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-938-5360
GSM: +49-178-782-6226