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
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
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
-- 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
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 http://martinaspeli.net/plone-book
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests