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

[Martin Aspeli]

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

Possibly, although that gets a bit tricky (or rather, counter-intuitive) 
since many types in portal_types may not be addable in many contexts. 
For types that filter content types, we can use the order in the 
allowable_content_types property. For types that don't filter, it'd make 
more sense to set a default order among globally addable types 
explicitly via a separate property/tab on portal_types.

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

Yeah. collective.wtf isn't a complete solution for a lot of things - it 
also ignores a bunch of things that are edge cases or never used in 
Plone, at least. It is, however, easier to work with that the 
workflows/*xml format in 90% of (Plone) cases. Anyway, that's moot here.

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

Yeah, I know. We'd need to look in the file for the id and meta type. 
See below.

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

How about we turn it on its head. If we have an importer that scans 
types/*.xml and looks for files to parse, it can create the objects in 
portal_types if they don't already exist. That should be safe for other 
import handlers too. And of course, it should be done defensively, so 
that if types.xml was present it was parsed first and types that exist 
would not be overwritten, as now.

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

I'm not sure most people think of portal_types as a "container" per se. 
Rather, they think "I need to register my content type, and for that I 
need an XML file that describes it". The fact that portal_types is a 
container for FTI objects is an implementation detail that probably 
doesn't belong too explicitly in the declarative GenericSetup syntax.

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

Mmmm.... I'm not sure I agree. Unless you happen to be intimately 
familiar with the implementation of TypesTool and WorkflowTool and other 
things, then these are not "the same" really. The use case is just to 
register types and workflow definitions. Each of those has a custom 
format anyway.

In general, I think warning signals should go off when we require people 
to type the same thing in more than one place or ensure that names 
"match" across multiple files and file names. It's far too easy to make 
mistakes, it's too easy to forget to change one during refactoring, and 
it's hard to explain and document. The DRY (Don't Repeat Yourself) 
principle that Grok has adopted is a great rule to live by.

I can see that there may be edge cases (e.g. ordering - but even then 
I'd rather there was an explicit directive to set the order) where we 
can't make a sensible, unambiguous inference. For those, we should keep 
the two-file format as an option. But I am pretty sure that no-one would 
complain if they didn't have to maintain a types.xml or put workflow 
definition lines in workflows.xml (obviously, bindings should stay there).

Martin

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