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 t
-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 no
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:
> 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 decl
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 initiali
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.
Howe
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, th
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 ski
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 i