-----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 [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 iD8DBQFIZ9hR+gerLs4ltQ4RAoewAJ96CC/sLjkqoAefA0b6Nyog6NptogCgpOIt yQLOHbzXzHdX0J9uScuzEc4= =xxgK -----END PGP SIGNATURE----- _______________________________________________ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests