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

[Tres Seaver]

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

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

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).  It is also not a given
that one knows unambiguously how to parse any give file in the types or
workflows directories.

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".  The redundant information is actually what
Yuppie specified:  the ID and metatype in the XML files.  Dropping that
information would be OK with me.

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.

So, -1 to removing / deprecating types.xml and workflows.xml.  +0 to
removing the redundant / ignored attributes in the corresponding XML
files for types and workflows.



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

iD8DBQFIZ9hR+gerLs4ltQ4RAoewAJ96CC/sLjkqoAefA0b6Nyog6NptogCgpOIt
yQLOHbzXzHdX0J9uScuzEc4=
=xxgK
-----END PGP SIGNATURE-----