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 - [email protected]
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
