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

[Martin Aspeli]

yuppie wrote:
> Hi!
> 
> 
> Martin Aspeli wrote:
>> The GS handlers for portal_types and portal_workflow both require a 
>> single file - types.xml and workflows.xml - that declares the objects, 
>> and a directory full of files - types/*.xml and workflows/*.xml - to 
>> initialise them.
>>
>> However, in both cases, there is enough information in the per-item 
>> files (id, meta_type) to make the types.xml and workflows.xml redundant. 
> 
> 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.

To what end?

It's not ordered now, and I can't see a good reason to make it ordered.

> 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?

A marginal one (no repetition), but this is still really cumbersome. I 
have to tell people to remember to add two files, and to match up three 
things (line in the types.xml, filename in types/*.xml, and line in 
types/*.xml file itself) just to install something.

FWIW, collective.wtf, which provides an alternate syntax for workflow 
installation, doesn't require a workflows.xml.

>> Worse, it's easy to forget, and no warning that there are "orphan" files.
> 
> Adding a warning might be an other solution.

That sounds like attacking the symptom rather than the problem, though.

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

True, but not very much. See 
http://dev.plone.org/collective/browser/collective.wtf/trunk/collective/wtf/exportimport.py#L128 
for an example.

In general, repetition like this is counter-productive. I've had to 
explain this to three people new to Plone recently, and it feels like 
I'm making excuses rather than a strong case.

We could add 10 lines of code and save 100 people from making common 
mistakes that cause problems of the type "why doesn't my workflow show 
up?" with no errors or warning messages.

I would probably not deprecate the existing two-file pattern though, 
just make it optional.

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book