-----BEGIN PGP SIGNED MESSAGE-----
Martin Aspeli wrote:
> yuppie wrote:
>> 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
>>> 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
> 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
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 Seaver +1 540-429-0999 [EMAIL PROTECTED]
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
-----END PGP SIGNATURE-----
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests