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


Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See

Zope-CMF maillist  -

See for bug reports and feature requests

Reply via email to