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

[yuppie]

Hi!


Martin Aspeli wrote:
> yuppie wrote:
>> 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.

It would be useful to specify the order in 'add' menus by ordering the 
type infos.

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

That code uses a hard-coded factory and the first part of the file name 
is used as 'id'. Right?

The types tool can contain many different objects: Several kinds of 
TypeInfos and scripts for ScriptableTypeInfos. You can't hard-code the 
factory, you have to parse the file to find out which factory is required.

But you can't be sure the file is an XML file of a specific format. The 
import/export adapter for scripts has a different format. I haven't seen 
an alternative adapter for TypeInfos, but right now you can plug in a 
different format (like CSV for workflows) by using a different 
import/export adapter.

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

I'm not happy with the current file format. But representing containers 
is a general problem and I want *one* generic solution that works for 
all use cases.

We have .objects files for content and .xml files for configuration. You 
propose a different pattern, and I doubt it could replace the other two 
patterns.


Cheers,

	Yuppie