Open tomcrane opened 2 years ago
Need to quantify what the existing set of behaviours are. We have the designs above implemented. In the storybook there is an example of setting multi-value behaviours.
Still needs some UI tweaks, but you can make them choices or multi-choice.
The config looks like this:
{
id: "pets",
label: { none: ["Choose pet"] },
type: "choice",
items: [
{ label: { none: ["None"] }, value: "" },
{ label: { none: ["Cat"] }, value: "cat" },
{ label: { none: ["Dog"] }, value: "dog" },
{ label: { none: ["Fish"] }, value: "fish" },
],
},
There are also type for: Template and "custom" options that have not yet been implemented.
At the moment the Manifest Editor offers a set of behavior options on the Technical tab for canvases and manifests:
These are just the values from the spec, which is wrong - not all behaviors are applicable to all resources (e.g., you can't set
repeat
on a Canvas as implied above). And we need to be able to apply behaviors to any resource.The config needs a map of resource
type
to lists of the permitted behaviors on those types. We need to be able to configure a default set (as per the spec), and then augment that with a further map for custom behaviors. So you don't lose behaviors when you configure your own additional ones.There is also more work that could be done to validate behaviors and prevent selection of disjoint behaviors on the same resource -
auto-advance
andno-auto-advance
are both permitted on canvases, but you can't have both on the same canvas.maybe something like this...
Then you could add another type -> behavior -> disjoints dictionary for your own custom ones. (An empty array for disjoints is of course allowed, and common).
So far so good... but there are two further behavior enhancements.
1) Also allow config to specify that any behavior can bet set as free text. This allows custom environments to be targetted without further configuration. It also avoids, as in Delft's case, hundreds of possible behaviors having to be listed in config.
2) Delft's custom behaviors can have lots of values because they look like
"behavior": ["info", "h-4", "w-4"]
- they are used for layout. But they do have a scheme to them - so rather than list all possible variations in config, or risk invalid values from free-text, we build a custom editing widget for these specific behaviors; other people can build custom behavior widgets for their own targets.