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
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
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
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,
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.
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
-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
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
-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
