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

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

types.xml is the absolute requirement:  it specifies what types the tool
knows about, including those for which there may be no XML file at all
in types/.  *If* the metatype in types.xml causes a type object to be
created which has a handler adapter registered for it, and that handler
chooses, it may then read and parse any number of arbitrary files from
the profile.  The stock handlers for FactoryTypeInformation and
ScriptableTypeInformation happen to read a single XML file, whose name
is derived from the ID of the type.

Likewise, workflows.xml is an absolute requirement.  Non-DCWorkflows,
for instance, may not have a corresponding subdirectory or
definition.xml file (they might be implemented entirely via imperative
logic).  The handlers for DCWorkflows are responsible for finding an
parsing the files in the subdirectory, including script files where they
exist.

The pattern is exactly the same for containers:  the container's handler
knows about what its objects are, and how to create them.  The handlers
for the individual objects can use zero or more additional files to
configure the objects after they have been created and seated into the
container.


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIaFXT+gerLs4ltQ4RAjNLAJ4zvhgbfUtjGKfHUzC/rY5GvHnY9QCgijXm
QX5tQtaYmAgRykdsFxOF0Cc=
=zkH9
-----END PGP SIGNATURE-----