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

[Martin Aspeli]

Tres Seaver wrote:

> One point of the types.xml file is that the type name may *not* map
> intuitively onto the name of the XML file (people seem determined to
> embed spaces in object names, for instance).

Sure. So now we rely on a not entirely obvious convention (space becomes 
underscore) and/or redundant information in the per-type file itself.

> It is also not a given
> that one knows unambiguously how to parse any give file in the types or
> workflows directories.

Why not?

> I strongly prefer the pattern that the tools state is stored in a common
> file, with per-object customization stored in separate files:  "explicit
> is better than implicit". 

I don't think it's implicit to say that if we have a file in types/*.xml 
with an id and a meta_type, then that object is created in portal_types 
- with that id and meta_type - if it doesn't exist.

> The redundant information is actually what
> Yuppie specified:  the ID and metatype in the XML files.  Dropping that
> information would be OK with me.

Sure, that reduces redundancy, but it still means that the information 
needed to install a type resides in two places, not once.

It's not entirely non-redundant, though. The id of the thing in 
types.xml and the filename have to match (with the space-to-underscore 
mapping).

> Note that both the workflow and the types tools *are* containers for
> arbitrary objects:  there are cases in the wild, for instance, which
> deploy non-DCWorkflow objects as workflow definitiions, and which have
> non-standard type info objects.  Using heuristic rules makes it harder
> to support such combinations.

I'm not sure I understand why it's harder. I'm not really talking about 
a heuristic, I don't think. Rather, I think the algorithm could be:

  - list all files in types/*.xml
  - read id
  - if it doesn't exist in portal_types:
  -- read meta_type
  -- create object of this type
  - else:
  -- fetch object with this id
  - populate with type info

As a bonus, we no longer depend on the file name matching the id 1:1.

The assumption here is that types/*.xml is reserved for the standard 
property-based type import/export handler. If I had a different type of 
FTI with a different parser, I'd need to pick a different directory.

I don't think that's any less reasonable than to say that types.xml (or 
propertiestool.xml or whatever) is specific to the default types 
import/export handler.

Is there any documentation anywhere that explains what types.xml is 
needed for and how it relates to types/*.xml? I've tried to explain to 
people why we need both, and I can't come up with a compelling argument, 
even after reading this thread. :-/

Martin

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