[Zope-CMF] Re: Why do we need types.xml and workflows.xml?
Martin Aspeli wrote: yuppie wrote: 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. For Plone users it might be an implementation detail. But even Plone users should know that importing GS profiles creates persistent objects. Pure CMF doesn't hide the implementation. The configuration data is stored in tools and sub-objects, GS maps them to directories and files. TTW configuration and GS configuration have the same structure, if you are familiar with TTW configuration you know where to find the same settings in a profile. Or the other way round. Cheers, Yuppie ___ 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
[Zope-CMF] Re: Why do we need types.xml and workflows.xml?
Hi! 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. Right now we have a relatively easy rule: Adding, moving or removing sub-objects modifies the container, so these changes *always* have to be specified explicitly in the container's file. 'id' and 'meta_type' in the per-item files are not really used. Would it be an improvement to remove that redundant information from the per-item files? Worse, it's easy to forget, and no warning that there are orphan files. Adding a warning might be an other solution. 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. Cheers, Yuppie ___ 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
Re: [Zope-CMF] Re: Why do we need types.xml and workflows.xml?
Am 29.06.2008 um 15:04 schrieb yuppie: 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. I suppose you could bundle all the information into a single types.xml file - like you can with skins but that then makes manual changes a bit trickier - if they are ever required. I find the current system where the file system mirrors the ZMI structure pretty helpful and I'd actually like to see it extended for things like the catalog indices. The biggest problem we have with this is when editing in the ZMI, exporting the XML and putting the XML files in the right folders: you get information from all the profiles in which case it's easy just to work with the individual type and update types.xml manually. Not sure how ordering fits in with this multiple profile setup but it would be pretty fiddly implementing it on a per file basis. Right now we have a relatively easy rule: Adding, moving or removing sub-objects modifies the container, so these changes *always* have to be specified explicitly in the container's file. 'id' and 'meta_type' in the per-item files are not really used. Would it be an improvement to remove that redundant information from the per-item files? I didn't realise they were both redundant! I would only remove them if they are also removed from the ZMI. Worse, it's easy to forget, and no warning that there are orphan files. Adding a warning might be an other solution. This would be a welcome addition to GS in general. I know I'm not the only who's been bitten by the fact that ZCML will complain bitterly about missing stuff which GS is happy to ignore. It doesn't matter that the only thing the two have in common is that they're XML. When developing new content types you add you package in zcml and type definition in GS. It would be nice if a type definition was expected but missing that this was raised. This would work with either approach. 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. Avoiding complexity is always a good argument! Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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
[Zope-CMF] Re: Why do we need types.xml and workflows.xml?
yuppie wrote: Hi! 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. Right now we have a relatively easy rule: Adding, moving or removing sub-objects modifies the container, so these changes *always* have to be specified explicitly in the container's file. 'id' and 'meta_type' in the per-item files are not really used. Would it be an improvement to remove that redundant information from the per-item files? A marginal one (no repetition), but this is still really cumbersome. I have to tell people to remember to add two files, and to match up three things (line in the types.xml, filename in types/*.xml, and line in types/*.xml file itself) just to install something. FWIW, collective.wtf, which provides an alternate syntax for workflow installation, doesn't require a workflows.xml. Worse, it's easy to forget, and no warning that there are orphan files. Adding a warning might be an other solution. That sounds like attacking the symptom rather than the problem, though. 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. 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. Martin -- 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 http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Why do we need types.xml and workflows.xml?
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. 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? 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. 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. 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. 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. Cheers, Yuppie ___ 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
[Zope-CMF] Re: Why do we need types.xml and workflows.xml?
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
[Zope-CMF] Re: Why do we need types.xml and workflows.xml?
-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
[Zope-CMF] Re: Why do we need types.xml and workflows.xml?
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. :-/ Martin -- 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 http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Why do we need types.xml and workflows.xml?
-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 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://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- ___ 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
